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PREFACE 


The ANOPP Programmers Reference Manual For Executive System embodies the documen- 
tation in its entirity for ANOPP as of release level 01/00/00. Additional manuals are 
anticipated in order to satisfy the various needs of the ANOPP user community. These 
anticipated manuals include the following: 

Theoretical Manual 
User’s Manual 

Demonstration Problem Manual 
Functional Module Writer’s Guide 

The Programmers Reference Manual is designed for usage by those who have need for 
understanding internal design and logical concepts of the ANOPP Executive System. Emphasis 
has been placed on providing sufficient information to the programmer in order to modify 
the system in pursuit of either enhancements or error correction. 
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INTRODUCTION 


1.1 PROGRAM OVERVIEW 

The Aircraft Noise Prediction Program (ANOPP) was developed to be a repository for 
current and future approaches to computerized study of aircraft noise. Today's methods 
are highly empirical; tomorrow's will be analytical. To the developer of new technology 
and prediction methods, ANOPP is where new algorithms and code can be deposited as a new 
or replacement part of an integrated system. To the planner or user, ANOPP is the 
source of current information and state-of-the-art prediction methods at selected 
levels of complexity for a suitably described model. 

With these objectives in mind, the fundamental design requirements of the system 
were defined as : 

1. flexibility for the addition, replacement, or removal of prediction 
methods 

2. user control for selective and effective use of the various methodologies 

The design requirements are met by separating executive functions from noise 
prediction functions. Thus, all of the noise prediction applications technology is con- 
tained in functional modules. 

The executive system provides for program initialization and interface with the 
host computer operating system. It provides for user control of execution via a control 
statement language processor. It provides storage management and data management for 
the functional modules. It provides error handling and exit procedures to the host 
operating system. 

The remainder of this chapter will outline the characteristics and motivations for 
several significant parts of the executive system. The interfaces and interactions 
between the executive and functional modules will be shown. The rest of this Programmer s 
Manual will provide more individual detail of the entire executive system. 


: 1 . 1-1 



INTRODUCTION ■ 


1.2 FUNCTIONAL MODULE CONCEPT 

A functional module is a logically independent group of subprograms or modules which 
performs noise prediction functions. The size varies with the number and type of modules 
required for the functions to be performed. 

A functional module is called into execution by the ANOPP executive system upon user 
request via a control statement. At the time of request the specified functional module is 
loaded into core and execution is begun. Upon completion the functional module returns 
execution control to the ANOPP executive system. An executive module is brought into the 
core space previously occupied by the now completed functional module to process the 
remaining control statements supplied by the user. Upon encountering a subsequent func- 
tional module request, the process is repeated. 

Thus a functional module is core resident if and only if it is being executed at user 
request. It is transient and shares the same core space with other functional modules as 
well as executive modules. 

General characteristics of functions include: 

1. Functional modules are independent. 

2. Functional modules do not call one another directly. 

3. Functional modules are called from and return control to the executive manager. 

4. Functional modules request and release storage through a dynamic storage manager. 

5. Functional modules input and output data through a data base manager. 
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1.3 CONTROL STATEMENT CONCEPT 

Just as the loading and execution of ANOPP is controlled by a set of job control cards 
monitored by the host computer operating system, so is the sequence of module executions 
within ANOPP controlled by a set of executive control statements monitored by the ANOPP 
executive management system. The control statements interpreted by the ANOPP executive 
manager provide: 

1. execution sequence control with branching 

2. exchange of parameters among the user, the executive manager, and the functional 
modules 

3. update capabilities for the ANOPP data base 

4. the ability to load/unload various parts of the ANOPP data base. 

The format for an ANOPP control statement is: 

label control statement name operand(s) $ optional comment(s) 

The structure and operand(s) appropriate to specific control statements can be found 
in Section 3.5.2 of this manual. Several general characteristics are of interest here. 

The label field provides tag addresses for looping and branching. The operands provide 
parameters for control of conditional branching and exchange of information among the user, 
the executive manager, and the functional modules. Control statements are terminated with 
a dollar sign ($); otherwise, they are assumed to be continued on the next card image. A 
limited number of continuation cards are permitted. Optional comments may follow the 
terminal character. 

A set of control statements in card image format is taken from the primary input 
stream, edited and stored in edited format on the data base. The statements are then 
executed one at a time from this edited set. A collection of control statements in un- 
edited or card image form may be saved in the ANOPP data base and subsequently retrieved by 
a CALL Control Statement in a later run. At the time of first execution of a CALL control 
statement, a specified pre-stored set of card image control statements is retrieved, 
edited and executed from beginning to end. Upon completion of the called set, execution 
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then continues with the control statement following the CALL. The control statements in 
edited form are saved for subsequent execution if required. The called set may itself 
contain further CALL statements in a cascading series of expansions, but the user must be 
careful to avoid an infinitely recursive CALL loop. While not currently implemented, the 
capability to interactively enter and interpret single control statements in a card image 
set is not precluded in the present design of the executive system. 
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1.4 DYNAMIC CORE CONCEPT 

Dynamic core is that portion of machine memory available within the program's region 
or field length that is not occupied by permanent or transient routines. This area is 
managed by a part of the ANOPP executive known as the dynamic storage manager. The total 
size of this dynamic core area varies directly with the field length available during an 
individual ANOPP execution. The capability provided by the dynamic storage manager is 
similiar to variable dimension arrays in FORTRAN and permits module writers to vary the 
size of data areas and to adjust their solution algorithms depending on the amount of core 
available. 

The total dynamic core area is divided into two parts : a Global Dynamic Storage area 

and a Local Dynamic Storage area. Global dynamic storage is of ,fixed length during a 
single ANOPP execution and resides at the end of the program’s region or field length. 
Local dynamic storage is of varying length and is bounded by the longest current transient 
routine on one side and by the start of global dynamic storage on the other side (see 
Figure 1). The dynamic storage manager allocates and de-a!16cates various size blocks up 
to the limits of the reserved space available for both local and global storage. Indivi- 
dual blocks of core within dynamic storage are defined by their starting location and 
length. The starting location is defined as an index relative to the variable IX in a 
fixed common block /XAN0PP/ that resides near the beginning of the program's region. The 
global storage area is available throughout a single ANOPP execution and is generally used 
for executive tables and control blocks required by the executive system. The local 
storage area is reserved and released during individual executive or functional module 
executions and is generally available as scratch space during the execution of these 
transient routines. While functional modules may use available space in global storage 
during their time of execution, they can not use global storage blocks as a means or 
mechanism for transmitting information or data to other functional modules directly. 
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1.5 ANOPP INPUT/OUTPUT 

The Input and Output files from the host computer operating system are readily 
available to the routines of the ANOPP executive system. They are less easily accessible 
by the functional modules. 

Functional modules receive and transmit their primary input/output via the ANOPP data 
base and the member manager and table manager facilities. There is no provision for 
reading directly from the host system input file. Information may be written directly to 
the host system output file; however, this should be done in conjunction with the execu- 
tive system paging routines (XPLINE, XPAGE , etc.) to insure accurate line counts and page 
headings. Functional modules can also exchange limited numbers of parameters via the 
PARAM control statements, the executive parameter functions (XGETP , XPUTP, XASKP), and the 
user parameter table. 

Since functional modules need information from the ANOPP data base to operate, the 
capability to place information in the data base must be provided. Thus, three control 
statements, DATA, TABLE, and UPDATE, provide means for reading cards from the primary 
input stream and transferring the information into the ANOPP data base in various selected 
formats . 
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1.6 EXECUTIVE MANAGEMENT 

The Executive Management System consists of the main executive monitor which controls 
the sequence of operation of the execution phases and the submonitors which control the 
operations within each phase. The first program executed is the executive monitor (XM) 
which immediately calls the XBS module to perform ANOPP system initialization. 

The executive bootstrap module (XBS) first checks to see that the required initial 
ANOPP control statements exist and are positioned correctly. XBS then initializes the 
global portion of dynamic storage via the dynamic storage manager, and executive and data 
base management tables and directories are allocated and initialized in dynamic storage. 
XBS returns to XM which calls the XRT module to edit the set of ANOPP control statements 
in the primary input stream and write the edited set on the data base to be executed later 
by the executive control statement processor module (XCSP). 

The executive module XRT edits the set of control statements from the primary input 
stream in one pass and writes them to the ANOPP data base in an edited control statement 
format that is structured for input to the executive control statement processing phase. 

In the edit phase, the syntax of each control statement is checked and labels are matched 
with their corresponding branching statements. The edit phase does not ’’execute 1 ’ the 
control statements, but simply transforms them from card image to ’’executable’ 1 format. . 
Then, the later processing modules can act more efficiently on the executable form that is 
well structured syntactically and contains label tables for efficient branching capa- 
bility. Several control statements have optional input following them. These control 
statements are DATA, TABLE, and UPDATE; and their input is terminated by an END* control 
statement before the next regular control statement. In these cases, the XRT module puts 
such input data on the data base and provides linking information so that this data can 
be retrieved during execution processing. The edit phase is complete and XRT returns to 
XM when an ENDCS card is found in the input stream. XM next calls the executive control 
statement processor module (XCSP) to execute the edited control statements. 
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The control statement processing module retrieves from the data base the edited form 
of the first control statement in the primary input stream and calls upon an appropriate 
executive module to process it. Upon process completion, control returns to the XCSP 
module which continues with the iterative pattern of read/process until the pattern is 
terminated by the ENDCS statement. The ENDCS indicates the set of control statements 
supplied by the user in the primary input stream has been completely executed and ANOPP 
should be terminated. The module which is called by XCSP to process the ENDCS thus per- 
forms normal termination procedures for ANOPP and does not return to XCSP. 

XCSP may be interrupted by either an error or a request for execution of a functional 
module via the EXECUTE control statement. In these two cases, control returns from XCSP 
to the executive monitor to determine what action is to be taken next. In all cases, the 
XCSP module remains in control and cycles through the read/process iteration for each 
control statement encountered. It is during this processing phase that the pre-stored set 
of control statements referenced by a CALL control statement is edited and processed 
before continuing with the next control statement. The edited form of the called control 
statement is written onto the data base and is available for subsequent retrieval. Thus 
editing is done only once at the first execution of the CALL statement. Any looping to 
re-execute the CALL statement will not cause redundant editing but only re-execution of 
the previously edited control statements. 

When control returns from XCSP to XM, either error processing or functional module 
execution is indicated. If error processing is indicated, XM calls the error module XMERR 
to perform action according to procedures discussed in Section 1.10. Regardless of action, 
XMERR always returns to XM upon completion. If functional module execution is indicated, 

XM calls XFM to control the loading, execution, and clean-up processes. The functional 
module can make use of any and all services of the dynamic storage manager, the data base 
manager, and the executive utilities. The only restriction is that the functional module 
cannot terminate abnormally, but must return control to XFM and thus to XM. XFM will 
perform some clean-up procedures if the functional module has neglected to release or 
close dynamic storage areas or data base structures. Control then returns to XM. 

1.6-2 


i 



EXECUTIVE MANAGEMENT 


When error processing or functional module execution has been completed, XM again 
calls the executive control statement processor module (XCSP) to continue executing the 
control statements. 

In summary, the executive management system first performs bootstrap initialization 
and edits the primary input stream control statement set. Then it cycles among control 
statement processing, functional module execution, and error handling until completion. 
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1.7 DYNAMIC STORAGE MANAGEMENT 

The ANOPP dynamic storage management system is a collection of modules that perform 
specific operations on the dynamic core areas discussed earlier. These modules are 
directly callable by the ANOPP executive and functional modules. Local dynamic storage 
and global dynamic storage are treated separately but equally by the modules of the 
dynamic storage management system. However, the modules of the executive management 
system do not treat them equally. The global dynamic storage area is initialized by the 
XBS module and never released during the rest of an ANOPP execution. Local dynamic stor- 
age on the other hand is initialized and released repeatedly by various executive modules 
and each functional module that makes use of it. For both types of storage, the remaining 
functions of dynamic storage management can be performed only during the time between 
initialization and release. 

The basic function of the dynamic storage manager is to allocate and de-allocate 
blocks of storage within the initialized dynamic storage areas. Each block is located by 
an index with respect to the variable IX in a fixed common block /XAN0PP/ . This index is 
generically referred to as the IDX of the block. When a dynamic core block is assigned to 
a calling module, the index (IDX) and length (LEN) are returned to the module. The 
module can then reference any location within the block by addressing between the limits 
of IX (IDX) to IX ( IDX+LEN-1 ) . Alternatively, the module can pass the argument IX(IDX) 
and LEN to a submodule that receives them as an array A of length LEN and can address any 
location within the block from A(l) to A(LEN). 

The initialization of a dynamic storage area consists of setting the boundaries with 
control words and declaring the remaining area to be one large free block. The size of 
the free block is reduced as reserved blocks are requested and assigned to calling modules. 
Eventually a reserved block will be freed by a calling module and it will be linked into a 
chain of free blocks along with the now reduced original free block. This process of 
reserving, reducing, freeing and chaining goes on until a request is made for more re- 
served space than is contained in any one of the individual blocks in the free chain. At 


ORIGINAL PAGE IS 
OF POOR QUALITY 


1.7-1 



INTRODUCTION 


this time a storage move takes place to consolidate all the fragmented free blocks into 
one large free block, unless storage has been locked at the request of a calling module. 
The IDX T s of all relocated reserved blocks are updated accordingly. If the requested 
space is not available, the calling module is informed that the length of the block 
assigned is zero. In this case the calling module may free some blocks and try again, may 
request less space, or may request space in the other (local/global) storage area. When 
all else fails, the user can rerun the job with more field length. 
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1.8 DATA BASE MANAGEMENT 

The ANOPP data base is a hierarchial structure from top to bottom and consists of: 

LIBRARIES 

UNITS 

MEMBERS 

RECORDS 

ELEMENTS 

WORDS 

A library is a collection of units, a unit is a collection of members, a member is a 
collection of records, a record is a collection of elements, and an element is a collec- 
tion of words. 

Paralleling the hierarchial data base is a hierarchial data base management system 
consisting of directories, control statements, and subroutines that operate on individual 
parts of the data base or between adjoining parts. For example,' the CREATE control state- 
ment establishes a new data unit while the UNL0AD control statement forms units or subsets 
of units into libraries. An overview of this parallel structure is given in Figure 1. 

Units are equivalent to files in the host operating system. The Data Unit Directory 
(DUD) contains a table of correspondence between internal ANOPP data unit names and external 
host operating system file names. The collection of data units named in the DUD defines 
the current data base for ANOPP execution. It consists of those data units that have been 
created, attached, or loaded up to this point, and that have not yet been detached or 
purged. The physical external file for a data unit contains a unit header, a member 
directory of current members on the unit, and the actual members and records themselves. 

For an attached, created, or loaded data unit in the DUD, a copy of its unit header is 

kept as part of its entry In the DUD. An operating system I/O buffer in global dynamic 

core is also associated with a data unit’s external file. 

1.8.1 Member Manager 

Below the level of unit is a member. A member and its substructures, records, ele- 
ments, and words, are managed by a set of Member Manager Subroutines. These routines are 
callable from both executive and functional modules. A member is a collection of records 
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Figure 1* Data Base and Data Management Parallels 
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of the same format. Records are not formatted in the sense of format conversion as with 
FORTRAN coded records. Rather, the format indicates the structure of the records by 
giving the types of the record elements. Element types specify whether the data is inte- 
ger, real, complex, single, double, or an alphanumeric string. The types are equivalenced 
to word lengths such as one word for an integer and four words for a complex double. 

Record reads and writes are really copying of binary data from/to external physical files 
to/from machine memory. The associated format provides a module writer with information 
for accessing individual record elements within sequential FORTRAN arrays. 

When a data member resides on a physical external file, it contains a member head 
followed by the records of the member. The member header contains record format informa- 
tion as well as a record directory and subdirectory of member records relative to the 
beginning of member. When a data member is open for I/O, its name is included in an 
Active Member Directory (AMD), and a Member Control Block (MCB) is assigned in Global 
Dynamic Storage. These entries point to the DUD entry for the unit on which the member 
resides. The DUD entry points to the last operating system file buffer for the external 
file. All of these thread back to a NAME array that is used in every Member Manager call 
for action on the member. 

The Member Manager routines provide capabilities to open, write, read, position, and 
close a member and its records. All calls to Member Manager subroutines provide a three 
word NAME array to indicate the data unit name and member name and to hold a pointer to 
the MCB. When a member is opened to read or write, a Member Control Block in dynamic 
storage is assigned and pointed to by the NAME(3) argument. The MCB points to the Active 
Member Directory entry for the open member and the Data Unit Directory entry for the unit 
on which the member resides. The Active Member Directory points both to the Data Unit 
Directory entry for the unit/member named and to the NAME argument supplied in the open 
call. The Data Unit Directory points to the External File Buffer (EFB) for the operating 
system file equivalenced to the data unit. See Figure 2, Diagram of Member Manager Di- 
rectory Connections. 
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All the records of a member occupy contiguous space on a data unit. Thus, when a 
member is open to write either sequentially or randomly, it often is necessary to actually 
write the records to a scratch unit until the member is closed. At that time all the 

records on the scratch unit are copied to the member's space on the real unit and the 

scratch unit is released. It is permissible to write records directly to a unit /member, 
but only one member at a time may be open for writing directly to the same unit. 

When a member is opened to read the following actions take place. The unit name is 
found in the DUD and its Member Directory is read into core through the External File 
Buffer (EFB). If the member is found on the unit, then a Member Control Block is assigned 
and the Member Header is read into the MCB area. A member open to read entry is made in 
the Active Member Directory. With all these connections established at open time, the 
Member Manager is now ready for subsequent read requests to transfer data from the exter- 
nal file into a central memory record holding area. Records can be read in whole or in 

part with partial records specified by either word length or number of elements. Members 

can be rewound and records can be read sequentially or randomly with the additional 
capability to skip forwards or backwards over records or to position directly to a speci- 
fied record. When closed, the MCB is released and if there are no other members currently 
open on the same data unit, the EFB is released also. The AMD entry is closed for reading, 
and if the member is not currently open to write also then the AMD entry is released. A 
member may be open to read and write concurrently since the member to be read must be an 
existing member in the current Member Directory for the data unit and the member open to 
write will go to a new place on the data unit and will not modify the Member Directory for 
the unit until the write process is closed. Since there is no re-write- in-place , read 
will continue to process the old version of a member while the new version is being written. 

1.8.2 Table Manager 

An ANOPP data table is a one record member. For this special class of members, the 
record holding area in dynamic storage into which the one record of the member is read is 
reserved and managed by the ANOPP Table Manager. The table name (unit/member) is held in 
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a Data Table Directory along with a pointer to the table (record) area in global dynamic 
storage. Thus, these tables can remain in core under control of Table Manager during the 
execution of several functional modules. Like other units/members, the units/members 
whose one record constitutes a table cannot remain open after execution of a functional 
module. It is only the table data in the record holding area that remains in core under 
control of the Table Manager. 

When a table is first opened, the unit/member is opened, the table record is read 
into core, and the unit/member is closed. The table name and a pointer to its core 
location is entered into the Data Table Directory. When the table is closed by the 
module that opened it, the table is logically closed in the DTD. A subsequent request to 
open the table will open it logically in core from the DTD. A request to close it will 
again close it logically. If a functional module opens a table Kith the intention of 
altering it, then it is rewritten to its real unit/member at the same time that it is 
logically closed in core. 

The Data Table Directory holds a fixed number of tables in core — some open, some 
closed. A request to open a table is first satisfied by opening the table if it is found 
in a search of the closed table chain in the Data Table Directory. If the table is not 
closed in core and available for re-opening, then an empty entry must be found in the DTD 
so that the unit /member /record for this table can be read into core and open member status 
can be entered into the DTD. If there are no free entries in the DTD, then one of the 
closed table entries will be released to make room for the new table entry. A subsequent 
request to open the table that was released will result in a fresh copy being read into 
core and re-entered in the DTD. If the DTD is full of open tables only, then no new 
tables can be entered and the job must be re-run with a new parameter value (NAETD) on the 
AN0PP control statement to initialize a DTD large enough to accommodate all the tables 
expected to be simultaneously open during the run. 
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1.9 UPDATE 

An update capability has been provided for manipulating the ANOPP data base by 
reconfiguring the members of a unit and/or changing the records of a member. This capa- 
bility has been provided at the ANOPP control statement level so that a user can control 
the outcome of an ANOPP execution by adjusting the data base prior to executing a func- 
tional module or unloading units of the data base to a sequential library* 

The update capability is patterned after the structured organization of the data 
base. For modifying data units, there are record level directives to add, copy, omit, or 
change a member. For modifying data members there are record level directives to insert 
and/or delete records. This capability is non -destructive. In no case are the records or 
members of a unit rewritten on the same unit. In all cases update executes from an old 
data unit to a new data unit, or to a new data unit alone if no old unit exists. Update 
can operate in full or partial mode. In partial mode, only those members mentioned on 
update directives are processed from the old to the new data unit. In full mode, all 
members are processed. 

One use of update is to reconfigure data units. This may be done to reduce wasted 
space on physical storage devices or to reorganize or combine members on a data unit in a 
manner more conducive to efficient execution by the intended ANOPP user . Another use is 
to create temporary data for use during an execution. 
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1.10 ERROR PROCESSING AND TERMINATION PHILOSOPHY 

ANOPP may terminate either normally or abnormally. Normal termination occurs when 
the ENDCS control statement is processed. Abnormal termination occurs when a fatal error 
inhibits further meaningful execution is encountered. 

Abnormal termination procedures are invoked whenever a fatal error is encountered by 
any executive module. Execution control is not passed back to the calling module by a 
return but instead a call is made directly to one of several error message modules. After 
printing an informative message, the message module calls the ANOPP abort module, XEXIT, 
to perform abnormal termination procedures and to terminate execution. Only executive 
modules have abort privilege. A functional module may never terminate ANOPP execution 
directly. However, abnormal termination may occur indirectly when a functional module is 
in core if an executive module, called to perform a service function, detects a fatal 
error. Abnormal termination will then occur as described. 

Errors which do not inhibit further execution are called non-fatal and are detected 
by either executive modules or functional modules. All errors detected by a functional 
module are non-fatal to the executive system. If a module is able to correct the error 
situation and continue processing, no further action is required. If, however, the module 
is unable to successfully complete its function, return is made to the executive management 
system with the executive error parameter NERR set to .TRUE. A functional module must not 
terminate abnormally but must return control to the executive management system. 

If an error occurs during either the initialize or edit phases of executive manage- 
ment, then execution continues and ANOPP is abnormally terminated upon completion of edit. 
Thus all errors in card image input are detected in one ANOPP execution. If an error 
occurs in later phases of processing control statements or execution of functional modules 
a return is made to the controller XM with NERR set as previously indicated. Subsequent 
action depends upon the system parameter JCON. Processing will continue with either the 
next control statement or the first encountered PR0CEED control statement. 
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2.1 SCOPE 

These standards define the requirements for preparing software for the Aircraft Noise 
Prediction Program (ANOPP). It is the intent of these standards to provide definition , 
design, coding, and documentation criteria for the achievement of a unity among ANOPP 
products. 

These standards apply to all of ANOPP f s standard software system. The standards as 
expressed in this publication encompass philosophy as well as techniques and conventions. 
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2.2 DESIGN 

2.2.1 Module Standards 

The Aircraft Noise Prediction Program will utilize the concepts of "composite design" 
for program structure. Composite design involves the construction of a program in terms 
of modular structure and module interfaces. 

A module is a group of program statements that can receive input data, perform one 
or more transformations on that data, and return output data. The modules for ANOPP will 
have the following general characteristics. 

1. The executable and comment statements for the module can be listed contiguously. 

2. The statements are enclosed by identifiable boundaries; e.g., in FORTRAN, 
from a PROGRAM or SUBROUTINE card to an END card. 

3. The statements are considered to be a discrete and identifiable entity that can 
be referenced from other parts of the program only by the module name or its 
single entry. 

4. The module can be referenced from other parts of the program only by the module 
name or its single entry. 

5. The module will have a single, common entry and a single, common exit. 

6. The module can reference or CALL other modules, suspend its execution upon 
encountering the CALL statement, and resume execution with the next immediate 
statement . 

7. All called modules must return to their caller at the statement immediately 
following the CALL statement. 

A module has three attributes: function, logic, and interfaces. For a composite 
design, a module should be described by its functions; i.e., what happens when the module 
is called. This characteristic can be described as data flow through the program A 
functional description of a module should contain a verb, such as, "Find Largest Block . 

A module’s logic describes the internal working or data flow within a module. Another 
attribute of a module, interconnection or interface, is concerned with module communication. 
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ANOPP modules will be designed to be as functionally independent as possible with 
minimum interface. Reliability , ease of understanding, and ease of maintenance are the 
objectives of these standards. 

Guidelines to be followed to achieve the standards of modularity for ANOPP are: 

1. Simplicity - Use the simplest solution, design and/or interface that is possible. 

2. Design efficiency - Design a module to solve the current problem efficiently; 
i.e. , never design a module to do more that it is required to do. 

3. Aligned control and effect - Align modules and decisions in modules so modules 
that are directly affected by a decision are beneath and controlled by the 
module containing the decision. 

4. High strength - Maximize binding, the relationships among the elements of a 
module. For high strength or binding modules should: 

a. have all elements related to the performance of a single function, 

b. have a single entry and a single exit, 

c. have a function which is easy to describe, 

d. be independent from other modules, 

e. be unsusceptible to errors from complex design and coding, 

f. be usable by other programs, and 

g. be modifiable without affecting other modules. 

5. Low interconnection - Minimize coupling, the relationships between modules. 

To attain the desired low interconnection or loose coupling, modules should: 

a. not directly reference other modules to: 

(1) modify a program statement, 

(2) refer to data in another module, 

(3) branch directly into another module, or 

(4) physically reside within another module; 

b. not pass control information to other modules; 

c. use only the following types of data interconnections: 

( 1 ) argument lists , 

(2) common areas, and 
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(3) data base members. 

6. Size - Limit the size of a module to 100 lines of executable source language 
statements. Clarity, simplicity, and understanding are related to module 
size. 

2.2.2 Depth of Design 

Program structuring involves an analysis of the problem, the flow of data through the 
problem, and the transformations that occur on that data. Equally, it involves identifi- 
cation and definition of modules to solve the problem. The phases of program structuring 
involve : 

1. definition of the structure of the problem, 

2. identification of the input and output in the problem, 

3. identification of the points of entry and exit for data, and 

4. reduction of the problem into a set of subordinate modules. 

A graphic representation of a module and subordinate modules will result in a hier- 
archy of modules. The graphic representation is called a "hierarchy chart" and should be 
drawn to illustrate the problem's solution. 

After the problem has been reduced into a set of subordinate modules, the process is 
repeated viewing each subordinate module as an independent problem that can be reduced 
into other subordinate modules . Some rules to follow are : 

1. The entire structure should be constantly reviewed to take advantage of modules 

that are identical. 

2. A module must be completely analyzed before its subordinates can be analyzed. 

3. The order in which modules at the same level are analyzed and reduced is not 
important. It is not necessary to analyze a module and all of its subordinates 
before starting another module. 

Conditions for terminating this iterative reduction process are: 

1. When a module can be reduced no further into independent functional modules. 

2. When further reduction of a module leads to the undesirable attributes of low 
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strength and high interconnections; i.e., low binding and high coupling. 

3. When the logic of a module can be completely visualized; i.e., usually resulting 
in less than 100 executable statements. 

4. When further reduction leads to highly specialized, unaligned, and inefficient 
sets . 

5. When the resulting documentation (Chapin-style charts) can be drawn on two or 
less sheets of 8^" x 11" paper. (One page is the desirable objective.) 

The final design phase of a module should follow these steps: 

1. A Chapin chart should be drawn to illustrate the module’s logic structure. 

2. Documentation should be set down to define the module’s purpose, inputs, outputs, 
local variables, functions, error conditions, control structures, data base 
structures, standards violations, and any additional explanatory remarks. 

This constitutes the first portion of the module’s prologue and is intended to 
be included with the source statement listing. 

3. A "walk through" of the module should be staged by the design team to insure 
workability. 

4. Pseudo code reflecting the logic structure outlined by the Chapin chart should be 
completed. This completes the module's prologue. 

2.2.3 Logic Structures 

All of the ANOPP modules will be logically designed so the execution flow will be 
sequential from one logic structure to the next logic structure. ANOPP module design will 
use four basic logic structures. Coding of a logic structure may require more than one 
executable source statement. No matter how complex the particular structure, upon comple- 
tion of its execution, the next structure will be executed. This sequential flow logic is 
characteristic of "top-down" design. The four logic structures are defined with tradi- 
tional graphics in the following paragraphs for educational value and comparison with the 
ANOPP standard Chapin charts* 
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2. 2. 3.1 Simple Sequence Structure 


2.2. 3. 1.1 Logical Flow Diagram 


2.2. 3. 1.2 Description 



Each statement within the structure is simple in that it performs one basic function 
e.g., an assignment of an evaluated expression to a variable or a call to another module 
(or subordinate). 


2.2. 3.2 IF THEN/ELSE Structure 
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2. 2. 3. 2. 2 Description 

The IF THEN/ELSE structure describes the flow sequence that occurs when there are two 
blocks of logic structure(s) and only one block should be executed according to a decision 
criteria or condition. The condition is a simple or a complex logical expression which 
has a value of True or False. If upon execution the condition is True, the logic struc- 
tured) of Block 1 (the THEN path) is(are) executed. If the condition is False, the logic 
structure(s) of Block 2 (the ELSE path) is(are) executed. When the last logic structure 
in the chosen path has been executed, control goes to the next logic structure or state- 
ment following the IF THEN/ELSE structure. This logic structure adheres to the "top-down 1 ' 
design in that the common entry is the point at which the condition is tested and the 
common exit leads to the next logic structure. 

2.2. 3.3 DO WHILE/DO UNTIL Structure 

2.2.3. 3.1 DO WHILE Logical Flow Diagram 



2. 2. 3. 3. 2 DO WHILE Description 

A block of logic structured) which may or may not be executed one or more times 
depending on a given condition is described by the DO WHILE loop structure. The loop 
structure adheres to "top-down" design in that the loop is entered at one point and flow 
within the loop progresses to one common exit point; i.e., the point at which the condi- 
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tion is tested. The condition is a simple or complex logical expression which has a value 
of True or False. The condition is tested at the beginning of the loop, before the 
execution of the logic structure(s) block, and if True, the logic structured ) is (are) 
executed. When execution of the logic structure(s) is(are) complete, control returns to 
the beginning of the loop and the condition is tested again. Looping continues until the 
condition is False; control then passes to the next logic structure following the DO 
WHILE structure. 


2.2. 3. 3. 3 DO UNTIL Logical Flow Diagram 



2. 2. 3. 3. 4 DO UNTIL Description 


A block of logic structured) which will be executed one or more times depending on 
a given condition is described by the DO UNTIL loop structure. The structure adheres to 
the "top-down" design in that the loop is entered at one point and flow within the loop 
progresses to one cornnon exit point; i.e. , the point at which the condition is tested. 

The condition is a simple or complex logical expression which has a value of True or 
False. The condition is tested at the end of the loop, after the execution of the logic 
structure(s) block, and if False the logic structured) block is executed again. This 
continues until the condition tested is True; control then passes to the next logic 
structure following the DO UNTIL structure. 


* *»* «x 


To 

X 
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2. 2. 3. 4 CASE Structure 


2. 2. 3.4.1 Logical Flow Diagram 



2.2. 3.4. 2 Description 


The CASE logic structure describes the flow sequence that develops when there are two 
or more blocks of logic structures, only one of which will be executed according to a 
given condition or decision criteria. The condition when evaluated must have a resulting 
value identical to one and only one of the conditions given (i.e., condition 1, condition 
2, ...., condition n). Control will pass to the beginning of the block identified by the 
matching condition. Upon completion of the chosen block, control will pass to the next 
logic structure following the CASE structure. The CASE structure adheres to the "top- 
down" design in that the structure is entered at one point, the test condition point, and 
after execution of the chosen block, control passes to one common exit and the next logic 
structure. 
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2.2.4 Design Documentation 

The design phase should result in a description of the structure of the program with 
descriptions of the module and intermodule interfaces. For the ANOPP project, the design 
phase will result in (1) hierarchy charts of the areas of the program, (2) Chapin charts 
with external specifications (module prologue) for each module depicted on the hierarchy 
charts, and (3) pseudo code. 

2. 2. 4.1 Hierarchy Charts 

A hierarchy chart will depict the results of the composite analysis process (top-down 
reasoning - structural process). This creative process is necessary to arrive at the 
modular logic and involves the analysis of the problem, the flow of data through the 
problem, and subdivision of the problem into modules that will perform transformations on 

the data. 

A hierarchy chart depicts each module, the level of the module (order), and the lines 
of communication for the module. In its optimal form, a hierarchy chart should be con- 
tained on one page (Figure 1). As an area can have several levels of modules, it may be 
necessary to place a module with its subsequent levels on additional pages; however, all 
subordinate modules on the same level should be placed on the same page. In the example 
illustrated in Figures 2 and 3 , five levels of modules are necessary. The submodules of 
the module "Control to Next Level" (Level 3) could not be depicted on the same page and 
were subsequently placed on an additional page. (Note the asterisk in the upper right 
corner of the "Control to Next Level" box. This indicates that this module is expanded as 
a separate hierarchy) 

Each module will have a short title, descriptive of its function, and a name that is 
used to reference the module. Module names should be descriptive of the function. 
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Figure 1. Hierarchy Chart: Basic Form 
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Figure 3. Haerarchy Chart: Basic Form 







DESIGN 


2 . 2 . 4 . 2 Chap in Charts 

A Chapin chart will be drawn for each module depicted on the hierarchy chart. The 
drawn Chapin chart will detail the internal logic of the module using simple control 
structures. In a structured program module, any program function can be performed using 
one of four control structures. The Chapin forms for these structures are: 

1. Simple sequence 

A 

B 

2. IF THEN/ELSE 


3. Repetition 




CASE I is really a generalization of the selection function (IF THEN/ELSE) from a 
two-valued to a multi-valued operation. 

Any kind of processing, any combination of decisions, and any sort of logic can be 
accomodated with one of these control structures or a combination of these control struc- 
tures. Each structure is characterized by a single point of transfer of control into the 
structure and a single point of transfer out of the structure. The control structures can 
be nested and still retain this characteristic. 
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A tricky situation, prevalent in current practice, arises when a designer desires to 
terminate a repetition block upon encountering a specific condition. If this termination 
is diagrammed as illustrated below, it violates the single entry/single exit principle 



of structured programming. However, equivalent logic is produced by using a multi-valued 
condition in the classical structure as shown below. 



A program utilizing these control structures tends to have no statement labels. (The 
actual implementation of these structures in a non-structured language like FORTRAN will 
require the use of statement labels. See Section 2.3 - CODING.) Utilizing these control 
structures in a top-down design eliminates arbitrary and capricious branching in a module 
and results in a more precise flow of data. 

The hand drawn Chapin charts (Figure 4) will be generated in the design process for 
formal "walk through" reviews of the structured design. The purpose of the review will be 
to uncover flaws in the design. The Chapin chart will enable the reviewers to examine the 
entire logic of the module. 

In addition to the use of the restricted control structures, the Chapin charts will 
also contain other attributes for ease of understanding. The chart will contairi the title 
and name of the module. The module name should be descriptive of the function performed 
by the module and is the name that is used to reference the module (for example, in a CALL 
statement ) . 
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CALL DECIDE( VAR1 , VAR2 ) 


ENTRY 

Set 

TAG to 1 for 1st CASE X 



DO WHILE TAG < 4 


DO CASE (1,1), (2,2), (3,3), (4,4), Depending on value of TAG 


1 

2 

3 

4 


CALL TAG1 

CALL TAG 2 

CALL TAG 3 

CALL TAG4 



IF TAG < 3 




ELSE 

_____ 

' 

THEN 


' __ If VAR2+TAG EVEN 

VARl+TAG EVEN 


ELSE 

THEN 

ELSE 

THEN 


CALL SMALL2 

CALL GREAT2 

CALL SMALL1 

CALL GREAT1 


Increment TAG by j 


exii 

" 


Purpose - To initialize TAG areas and build tables. 


Cate - Designed/9/30/75, JD - Coded/10/15/75, MP 

Functions - Call individual TAG areas in sequence. On the 

first two passes, build a small or large type one 
table first depending upon the value of the input 
parameter VAR1 . On the next two passes, build 
a small or large type two table first depending 
upon the value of the input parameter VAR2. 


Inputs - VAR1 = 1 if Great Table 1 is to be built first 

VAR1 = 2 if Small Table 1 is to be built first 

VAR2 = 1 if Great Table 2 is to be built first 

VAR2 = 2 if Small Table 2 is to be built first 

Outputs - None 


Figure 4. Typical Chapin chart with external specifications. 
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The language for the Chapin chart should not be cryptic to the point that only the 
designer understands the logic. Neither should it be so wordy that it can T t fit in the 
box. 

The use of the IF THEN/ELSE control structure will sometimes result in a do-nothing 
or NULL statement from the question. It is preferred that the NULL statement be designed 
and implemented from the ELSE path of the question. 

Module lengths should be limited to a manageable size. No firm rule can exist for 
size; however, the tendency is to have between 10 and 100 lines of executable statements. 
With this size, a single entry, single exit, and no arbitrary jumps to other parts of the 
program, there is little need for page-turning or holding several places which must be 
referenced constantly. 

The function performed by the module should be described irv a single sentence fol- 
lowed by an expanded description, if necessary. The expanded description can be a narra- 
tive description, tables, etc., and should be easily adaptable to card format for inclu- 
sion in the programming documentation. 

There should be a precise description of all input and output data for the module. 

It should include all parameters, any physical order, size, type, and range of valid 
values. A full description of module interconnections is necessary as it will usually 
affect any calling module. Any external effects should be explained, e.g., the reading of 
a tape or printing. 

The module name, functional description, input and output description, and external 
effects will be called the module’s external specifications. For design, these items will 
be placed on the Chapin chart and/or additional pages if necessary. These items will be 
prepared to be carried onto the program listing as the first half of a module* s prologue. 

2. 2.4.3 Pseudo Code 

After the design "walk through" and approval, the Chapin chart will be converted into 
indented control structure pseudo code in punched card format. This will constitute the 
second half of the module’s prologue. 
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Pseudo code , English phrases derived from the Chapin chart, describes the flow of the 
control structure. The simple sequence is a statement. The IF THEN /ELSE structure is 
divided into three parts: (1) IF Is usually a one line question; (2) THEN is a statement 
to be executed if the answer is true; and (3) ELSE is a statement if the answer is false. 
The THEN statement and/or ELSE statement can be followed by other questions and/or state- 
ments. The DO UNTIL, DO WHILE, and CASE are statements. 

The pseudo code acts as a bridge between the design and coding phases. It is a 
transformation of the highly graphic, parallel vision, Chapin charts into a form similar 
to the top-down, straight line, final source code. As such, there are several guidelines 
for converting the Chapin charts to pseudo code. 

1. All decisions which alter the simple sequence flow of the program will be shown. 
If, during coding, a FORTRAN flow altering statement is introduced, it must be 
reflected in the pseudo code. 

2. All FORTRAN CALL statements must be reflected as a simple sequence statement 
in pseudo code. 

3. Each FORTRAN statement which is a simple sequence type does not require a match- 
ing statement in the pseudo code if it is part of a group of FORTRAN statements 
which performs a common pseudo code statement. 

Example : 

PSEUDO CODE FORTRAN STATEMENT 

Calculate X, Y, Z coordinates X = 

Y = 

Z = 

4. The control statements IF, DO WHILE, DO UNTIL, and CASE always denote additional 
statements will follow. Each of these control statements will use an appropriate 
END statement to denote the end of a particular set. The END statement will be 
indented the same number of columns as its subject. The END statements are 
ENDIF, ENDDO, and ENDCASE. 

5. The pseudo code will be written in a format with strict indentation in each 
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group and subgroup of statements for ease of understanding and clarity. 
Section 2.3.1 - Source Code Documentation for specific rules. 


See 
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2.3 CODING 

To ensure ease of understanding, maintaining, and interchanging of ANOPP code, 
certain standards will be imposed. These standards encompass both documentary comments 
and specific language statements. It is recommended that any exceptions to standards be 
employed only within the bounds of a specific module and not be allowed to couple with 
other modules. 

2.3.1 S ource Code Documentation 

Comment statements in any programming language are both source code and documentation, 
Thus, various kinds of descriptive information which would normally appear in publishable 
programming documentation can be captured as comments in the source code also. For ANOPP, 
design and documentary information will be brought together and placed in the program 
source listing. This information will be contained in a special module prologue section 
at the beginning of a routine and in regular comment statements interspersed among the 
executable statements of a routine. The prologue section should explain the purpose and 
functioning of a routine as well as the flow of control within the routine. If any coding 
standard is violated, it must be noted in the prologue and, as an additional comment, in 
the executable statements. The in-line comments are supplementary in nature and should 
explain special cases or values and other non-obvious implementations. 

The first line of a routine is the program header, be it PROGRAM, SUBROUTINE, FUNC- 
TION, BLOCK DATA, or IDENT. The module prologue will appear immediately following the 
program header and preceding any other lines of source code. The source code and optional 
comments will follow the prologue. 

The module prologue contains both descriptive information and a pseudo code transla- 
tion of the module's Chapin chart. The definition of prologue contents and format is 
given below. An example of a prologue is illustrated in Figure 1. 
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ANOPP PROLOGUE FORMAT 


COLUMN 

0 0 1111 

1 5 0 2 4 6 


ftftft 

* PURPOSE - short description of subprogram function (1-2 sentences) 

* AUTHOR - initials (level number such as L01/00/00) 
ft 


INPUT 

ARGUMENTS 

Name^ - description 


ft 


ft 

ft 

ft 

ft 


ft 

ft 

ft 


ft 

ft 

ft 

ft 

ft 

ft 

ft 

ft 

ft 

ft 


Name - description 
OTHER n 

/common block name/ 

Name^, . . . .Name^ - described in subprogram name 
or 

/common block name/ 

Name - description 


Name - description 
or 

Verbal description if required 

(For common variable, only those applicable to the module should be 
listed. The full description of each variable is required for major 
modules. However, for sub-modules, a reference to where the description 
can be found is sufficient.) 


OUTPUT 

ARGUMENTS - same as for INPUT 
OTHER - same as for INPUT 


* LOCAL VARIABLES 

* Name - description 

* . 1 


* 

* Name n - description 

* FUNCTIONS 

* 1. Function. 

A 

* 

* 

A n. Function 

ft n 

* CONTROL STRUCTURES 

* Description of control structures or reference to description in another 

a subprogram or published manual. Control Structures include core tables, 

* directories, control blocks, etc. 

* 
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DATA BASE STRUCTURES 

Description of control structures or reference to description in another 
subprogram or published manual. Data Base Structures are unit, member, and 
record structures. 

SUBPROGRAMS CALLED 

Subprogram^ , . . . , Subprogram^ 

ERRORS 

NON-FATAL 

1. Condition (error message class and number) 


n. Condition (error message class and number) 
FATAL 11 

same as for NON-FATAL 

STANDARDS VIOLATIONS 
1. Short description 


n. Short description 


*** 


REMARKS 

Additional comments 


* ENTRY N , .. 

Pseudo Statement (in columns 10, 15, 20, etc.) - simple sequences and the 

* following sets of key words should be aligned in order within a set: IF, THEN 

* ELSE, ENDIF; DO CASE, CASE, ENDCASE ; DO WHILE, DO UNTIL, ENDDO. Subsequent 

V; substructures should be indented 5 spaces. 

* EXIT 
*** 


The headings PURPOSE, AUTHOR, INPUT, OUTPUT, FUNCTIONS, ERRORS, AND SUBPROGRAMS - 
CALLED will be mandatory. If a mandatory heading is not applicable, "None" should be 
indicated after the heading and all subheadings omitted (e.g. INPUT - NONE). If a 
mandatory heading is applicable, all subheadings under it must be specified. The 
headings LOCAL VARIABLES, CONTROL STRUCTURES, DATA BASE STRUCTURES, STANDARDS VIOLATIONS, 
and REMARKS are optional and, if not applicable, should be omitted. 

The statements in the pseudo code should be labeled with statement numbers where 
appropriate. These numbers should be in numerically ascending sequence from the top 
down. Corresponding FORTRAN statements in the source code should be similarly numbered in 
the same top-down sequence. 
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INTEGER FUNCTION NWDTYP( I TYPE ) 

PURPOSE - DETERMINE THE NUMBER OF WORDS REQUIRED FOR A DATA 
TYPE GIVEN ITS ANOPP INTEGER TYPE CODE. 

AUTHOR - SSS(L01/00/00) 

INPUTS 

ARGUMENTS 

I TYPE ANOPP INTEGER TYPE CODE 

OTHER 
/XCVT/ 

NDTCL, NMH, NCPW - DEFINED IN /XCVTBD/ 

OUTPUT 

INTEGER FUNCTION VALUE OF NUMBER OF WORDS IN FIELD 
FUNCTIONS 

1. DETERMINE THE NUMBER OF WORDS IN A FIELD GIVEN ITS TYPE 
CODE 

2. VALIDATE TYPE CODE 

INVALID CODES ARE ZERO AND OUT OF RANGE STRING VALUE 
DATA STRUCTURES 

SEE ANOPP PROGRAMMERS REFERENCE MANUAL FOR FULL 
DESCRIPTION 

1. ANOPP DATA TYPES TABLE 


" SUBPROGRAMS CALLED 

* XUFMSG 

* 


ERRORS 

* NON-FATAL - NONE 

* FATAL 

* 1. INVALID ANOPP TYPE CODE 

* XUFMSG ERROR MESSAGE NUMBER 4 


* 

* 

* 

* 

* 

ft 

it 

it 


it 

it 

it 

it 

ititit 


ENTRY 

IF TYPE CODE IS BETWEEN 1 AND 10 

THEN FIND NUMBER OF WORDS IN ANOPP DATA TYPES TABLE 
10 ELSE IF FIELD ILLEGAL (TYPE CODE GREATER THAN 20) 

THEN COMPUTE NUMBER OF WORDS FROM CODE 

20 ELSE IF FIELD CHARACTER STRING (TYPE CODE BETWEEN -1 AND 

-132) 

THEN COMPUTE NUMBER OF WORDS FROM CODE 
30 ELSE ILLEGAL TYPE CODE 

ABORT WITH MESSAGE 

40 ENDIF 

50 ENDIF 

60 ENDIF 
EXIT 


Figure 1. Prologue and executable statement listing. 
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LOGICAL NERR 



COMMON 

/XCVT/ 

NERR 

,NEXPND 

1 

,NDT 

,NDTCL( 12,3) 

,NBPW 

2 

,NCPW 

,NBPC 

,NMH 

3 

,NTNAME 

,NTMAX 

,NTCUR 

4 

,NTENT 

,NTSTRT 

,NT3USD 

5 

,NT3FRE 

,NT30TR 

,NT3STR 

6 

, IWR 

, IRD 

,LENGL 

7 

,NWPCI 

,NMCPW 


IF ( ( ( 

ITYPE. LT.l 

) . OR. ( ITYPE. GT. 10 )) GO 

TO 10 


NWDTYP = NDTCL( ITYPE, 3) 

GO TO 60 

10 IF ( ITYPE.LE.20 ) GO TO 20 
NWDTYP ~ ( ITYPE-21+NCPW )/NCPW 
GO TO 50 

20 IF( ( ( ITYPE. GE.O ).OR.( ITYPE. LT. -NMH ) ) GO TO 30 
NWDTYP = ( -ITYPE+NCPW- 1 ) /NCPW 
GO TO 40 

30 CALL XUFMSGC 4, 6HNWDTYP , 5HITYPE , ITYPE ) 

C THE CALL ABOVE SHOULD ABORT 

C THE STOP BELOW INHIBITS ILLOGICAL EXECUTION 

STOP 

40 CONTINUE 

50 CONTINUE 

60 CONTINUE 
RETURN 
END 


Figure 1. Prologue and executable statement listing. (Continued) 
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Section 2.2.4. 3 described the design conversion from Chapin chart to pseudo code. 
Section 2.3.2 will describe the translation from pseudo code to FORTRAN source code. 

Thus, the pseudo code in the prologue is a highly visible bridge between the module as 
designed and the module as coded. Capturing this documentation in the source code will 
simplify the tasks of understanding, testing, and maintaining a module's code. 

2.3.2 FORTRAN Language Standards 

The requirements of ANOPP will impose certain restrictions on the use of the normal 
FORTRAN language for two reasons. First, the requirement for machine independence demands 
the use of a FORTRAN subset that operates compatibly on several manufacturer's computers. 
Second, the set of requirements for structured programming and its attendant simple logic 
structures demand several implementation algorithms since FORTRAN is not a structured 
programming language. 

2. 3.2.1 Machine Independence 

FORTRAN, a high level compiler language, is relatively machine-independent. Even so, 
standard FORTRAN (ANSI X3. 9-1966) has not been implemented by the same or different manu- 
facturers to be completely independent of machine architecture. However, a fundamental 
precept of ANOPP development is to minimize implementation and conversion problems on the 
major third generation scientific computers (CDC CYBER series, IBM 360/370 series, UNIVAC 
1100 series). To this end, ANOPP code will conform to ANSI standards as defined in the 
FORTRAN Extended Version 4 Reference Manual subject to the restrictions listed below. 

NON-ANSI constructions (indicated by shaded areas in the reference manual) must not 
be employed. The following are standards that are to be followed to maximize machine 
independence . 

31 

1. The magnitude of an integer constant or variable may not be greater than 2 -1. 

2. Subscripted variables should contain no more than 3 subscripts. 

3. Array variables must be referenced with explicit subscripts, e.g. , A(l) = 0, 
not A = 0. 
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4. A CONTINUE statement requires a FORTRAN statement number. 

5. The PAUSE statement is not to be used. 

6. The NAMELIST statement is not to be used. 

7. Implied DO's in DATA statements are not allowed. An array name without sub- 
scripts is allowed although it is an ANSI violation. 

8. The last statement of a DO loop may not be a logical IF statement. 

9. BLOCK DATA subprograms may contain only type (e.g., REAL, INTEGER), DIMENSION, 
COMMON, and DATA statements. 

10. All variables containing Hollerith data should be limited to eight character*, 
left-justified and blank-filled. The forms nL and nR should not be used for 
Hollerith data. The form nH should be used. When using Ai format specification, 
i must not exceed 8. A3, A6, A8 are valid; A10 is invalid. 

11. Packed fields within a computer word should not be used. 

12. Octal (0 or B) or Hex (Z) in DATA or FORMAT statements may not be used. 

13. Specification statements should precede any executable statement. 

14. The order of specification statements should be as follows: 

COMPLEX 

DOUBLE PRECISION 

REAL 

INTEGER 

LOGICAL 

EXTERNAL 

DIMENSION 

COMMON 

EQUIVALENCE 

DATA 

15. The variables in a COMMON block should be ordered as follows: complex, double 

precision, real, integer, and logical. 

16. Variables stored as single precision cannot be referenced as double precision 
variables (via the FORTRAN EQUIVALENCE statement) because of the different 
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internal word storage format for single and double precision words. 

17. Caution must be exercised to insure that types (REAL, INTEGER, etc.) of FORTRAN 
functions agree in the function subprogram and in the calling program. This 
agreement between types is necessary for machines (e.g., IBM 360) in which 
REAL and INTEGER values of FORTRAN functions are returned in different regis- 
ters . 

18. No attempt to extend the length of arrays through the EQUIVALENCE statement 
should be made. 

19. Caution must be exercised when using the EQUIVALENCE statement. Optimizing 
compilers do not guarantee that the values used for the equivalenced variables 
will be the expected value. Hence, EQUIVALENCE should be used only between 
variables which have non- intersecting use spans in a program. Storage and 
retrieval of a variable value is not necessarily in the order given by FORTRAN 
source. 

20. Multiple entry routines and routines with nonstandard returns are not to be 
used. 

21. There must be agreement with respect to the number of arguments and the type 
of each argument in the argument list of a calling program and the called 
subroutine. 

22. Only the carriage control characters "l” and "blank" may be used to control 
printer spacing. No spacing or suppression of spacing characters may be used. 

23. Modification of the length of an explicit type declaration (e.g., REAL*8) is 
not allowed. 

24. Deck (or member) names for subroutines should be six or less characters and 
should agree with the primary entry point names. Deck names for Block Data 
subprograms should end with the characters "BD". 

25. FUNCTION subprograms whose type is not implicit must be typed in the FUNCTION 
statement. For example, use 

DOUBLE PRECISION FUNCTION ABC( X ) 

and not 
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FUNCTION ABC( X ) 

DOUBLE PRECISION ABC 

26. The name of a FUNCTION subprogram must appear somewhere within the subprogram. 

27. All subscripted variables appearing in EQUIVALENCE statements must be subscripted, 

e.g., use EQUIVALENCE (A(l), X(l)) instead of EQUIVALENCE (A,X). 

17 

28. DO loop indices may not be greater than 2 - 1 (131,071). 

29. Logical operations are permitted on non-logical variables only using supplied 
functions IAND, IOR, ICOMPL, IXOR. 

30. Subscripts may not contain subscripted variables. 

31. Actual subroutine parameters that are changed by the called subroutine must 
have unique locations. 

Example: CALL SUB( A, A ) where SUB is as follows: 

SUBROUTINE SUB( C, D ) 

C = 10 
RETURN 
END 

is not allowed. 

32. No DATA statements for variables in common blocks outside BLOCK DATA programs 
will be used. 

33. Blank common will not be used. 

34. ENCODE, DECODE, or similar installation or machine dependent routines will 
not be used. 

35. Branching into the range of a DO statement is not allowed. 

36. It is preferred that the use of constant numbers for referencing or indexing 
tables be restricted. 

2. 3. 2. 2 Structured FORTRAN 

FORTRAN is not a structured programming language. FORTRAN syntax does not directly 
include the logic constructs defined in Section 2 . 2.3 and Section 2 . 2.4 of this document. 
However, several implementation algorithms can be defined to permit adherence to the 
concept of structured programming. 
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2. 3. 2. 2.1 Simple Sequence 

FORTRAN syntax permits easy implementation of the simple sequence structure. There 
is no need for statement numbers within the sequence except for format statements that do 
not alter the flow of execution. Entry to the sequence may require a statement number if 
it is entered as the result of a previous branching structure. 

Example : 

Pseudo Code FORTRAN Code 

GET X READ 100, X 

COMPUTE SQUARE ROOT OF X SX = SQRT( X ) 

PUT RESULT PRINT 100, SX 

2. 3. 2. 2. 2 IF THEN/ELSE 

FORTRAN syntax does not include an IF THEN/ELSE structure. However, various combin- 
ations of Arithmetic If, Logical If, Go To, and Continue statements can provide the two- 
branch logic desired. The rules for their use are as follows: 

1. The THEN path must precede the ELSE path in top-down order in both the pseudo 
code and the FORTRAN code. 

2. The ENDIF statement must be represented by a numbered Continue statement. 

3. The Arithmetic If statement with two of the three branches equal is the preferred 
implementation . 

4. The Logical If must be used with logical variables or multiple relational expres- 
sions. 

5. The Logical If must be implemented with a .NOT. condition and a Go To the 
ELSE path. 

Example 1 : Arithmetic If 

Pseudo Code FORTRAN Code 

IF ANGLE .LE. 180 IF( PI - THETA ) 2, 1, 1 

or 

IF( THETA - PI ) 1, 1, 2 

1 THEN COMPUTE SIN( ANGLE ) 1 SINTH = SIN( THETA ) 

GO TO 3 

2 ELSE COMPUTE - SIN( 180 - ANGLE ) 2 SINTH = -SIN( PI - THETA ) 

3 ENDIF 3 CONTINUE 
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FORTRAN Code 

IF( .NOT. ( SWITCH ) ) GO TO 1 
CALL SUBA 
GO TO 2 

1 CALL SUBC 

2 CONTINUE 


FORTRAN Code 

IF( X ) 1,2,2 (preferred) 

or 

IF( . NOT . ( X.LT.O ) ) GO TO 2 

1 X = ABS( X ) 

2 CONTINUE 


2. 3. 2. 2. 3 CASE 


DO CASE (condition 1, statement 1) ....(condition n, statement n) on test variable 

The DO CASE structure can be implemented with a variety of programming techniques 
employing a combination of Go To, Computed Go To, Logical If, Arithmetic If, and Continue 
statements. In all cases the ENDCASE statement must be represented by a CONTINUE state- 
ment with a statement number. Four basic examples are illustrated. 

Example 1: Integer Test Variable 

Pseudo Code FORTRAN Code 

DO CASE (1,1) (2,2) (3,3) (4,4) GO TO (1, 2, 3, 4, 5) I 

(5,5) on I 

1 Process Control Statement 1 1 CALL PRCS1 

GO TO 6 

2 Process Control Statement 2 2 CALL PRCS2 

GO TO 6 

3 Process Control Statement 3 3 CALL PRCS3 

GO TO 6 

4 Process Control Statement 4 4 CALL PRCS4 

GO TO 6 

5 Process Control Statement 5 5 CALL PRCS5 

6 ENDCASE 6 CONTINUE 


Example 2: Logical If 

Pseudo Code 

IF SWITCH IS TRUE 
THEN CALL SUBA 

1 ELSE CALL SUBC 

2 ENDIF 

Example 3: ELSE path null 

Pseudo Code 

IF X ,LT. ZERO 

1 THEN X = ABS( X ) 

ELSE NULL 

2 ENDIF 
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Example 2: Arithmetic If 

Pseudo Code 

DO CASE (-,1) (0,2) (+ ,3) on X 

1 SX = SQRT( -X ) 

2 SX = 0 

3 SX = SQRT( x ) 

4 ENDCASE 

Example 3: Logical If with an executable statement 

Pseudo Code FORTRAN Code 

DO CASE ( "A" ,1 ) ( M B M ,2) ("C",3) 

( M D M ,4) on NAME 

1 CALL SUBA 

2 CALL SUBB 

3 CALL SUBC 

4 CALL SUBD 

5 ENDCASE 

Example 4: Logical If with Go To 

Pseudo Code FORTRAN Code 

DO CASE ("A", 1) (”B",2) ("C",3) 

( M D",4) on NAME 

1 CALL SUBA 

2 CALL SUBB 

3 CALL SUBC 

4 CALL SUBD 
5 ENDCASE 

2. 3. 2. 2. 4 DO WHILE (condition) and DO UNTIL (condition) 

The DO WHILE structure implies that condition testing is done before the sequence of 
operations is performed. The DO UNTIL structure implies that the sequence of operations 
is performed at least once before condition testing is done. These structures can be 
implemented in FORTRAN with various combinations of Arithmetic If, Logical If, Go To, 
Continue, and Do statements. The possible variations are too myriad to enumerate speci- 
fically. However, the following standards will promote adherence to the spirit of top-down 
structured programming. 


IF ( NAME.EQ . 1HA ) GO TO 1 
I F ( NAME . EQ . 1HB ) GO TO 2 
IF( NAME.EQ. 1HC ) GO TO 3 
IF( NAME.EQ. 1HD ) GO TO 4 
GO TO 5 

1 CALL SUBA 
GO TO 5 

2 CALL SUBB 
GO TO 5 

3 CALL SUBC 
GO TO 5 

4 CALL SUBD 

5 CONTINUE 


1 IF( NAME.EQ. 1HA ) CALL SUBA 

2 IF( NAME.EQ. 1HB ) CALL SUBB 

3 IF( NAME.EQ. 1HC ) CALL SUBC 

4 IF( NAME.EQ. 1HD ) CALL SUBD 

5 CONTINUE 


FORTRAN Code 

IF ( X ) 1, 2, 3 

1 SX = SQRT( -X ) 
GO TO 4 

2 SX = 0 
GO TO 4 

3 SX = SQRT( X ) 

4 CONTINUE 
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1. A Do statement can be used for a DO UNTIL with an incrementing condition. 

2. If a Do statement is used for a DO WHILE , then the condition must be tested 

as the first statement inside the Do or as the statement immediately preceding 
the Do if it is an incrementing condition with variables instead of constants. 

3. All FORTRAN Do loops must end with a numbered CONTINUE statement. 


2. 3.2. 2. 5 CONTINUE 


A CONTINUE statement is used if required to insure that the DO WHILE or DO UNTIL will 
stand alone (i.e., not depend on the previous or next pseudo code structure). A labeled 
CONTINUE statement can therefore appear in the FORTRAN code with a label number not 
appearing in the Pseudo code. The label numbers should, of course, appear sequentially m 
the FORTRAN code. Examples 1, 3, and 4 show a labeled CONTINUE not shown in the Pseudo 
code but required for implementation. Example 2 shows the absence of any CONTINUE state- 
ment . 

Example 1 

Pseudo Code FORTRAN Code 

DO UNTIL ( TABLE ( I ) = NAME FOR DO 9 I = 1 , LTAB 

I = 1 to TABLELENGTH) 


10 ENDDO 
Example 2 
Pseudo Code 

10 DO UNTIL A EQUALS B 
ENDDO 
Example 3 
Pseudo Code 

DO WHILE ( I.LE.K FOR I = J 
TO K) 


9 CONTINUE 
10 CONTINUE 


FORTRAN Code 
10 

IF ( N.NE.B ) GO TO 10 

FORTRAN Code 

IF ( J.GT.K ) GO TO 10 
DO 9 I = J, K 


10 ENDDO 


9 CONTINUE 
10 CONTINUE 
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Example 4 


Pseudo Code 


9 DO WHILE ( A.EQ.B .OR. C 
.GT.D ) 


FORTRAN Code 


9 IF ( .NOT. ( A.EQ.B .OR. C.GT.D ) ) 
*GO TO 10 


10 ENDDO 


GO TO 9 
10 CONTINUE 


2.3.3 Assembly Language Standards 


There is no unique assembly language that is compatible across several manufacturers f 
computers. The assembly language standards for ANOPP, then, fall into two categories: (1) 
general requests to adhere to the spirit of structured programming and (2) specific 
interface requirements between FORTRAN and assembly language subroutines for a given 
machine. 


2.3. 3.1 General Rules 

The following general rules will promote clarity and understanding while adhering to 
the spirit of structured programming. 

1. Each routine shall have a module prologue as described in Section 2,3.1. 

2. Multiple entry points and non-standard returns are not allowed. 

3. Self -modifying code is not permitted. Instructions can change data only, 
they cannot change other instructions. 

4. Assembly code must follow the same top-down order as the pseudo code. 

5. Liberal use of comments is recommended for clarity and understanding. 

6. The prologue* s pseudo code should be repeated in appropriate comment fields 
of assembly statements. 

7 . Local macro definitions should be found after the prologue at the beginning 
of a routine. 

8. System macros should briefly be explained and a document reference cited. 
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2. 3. 3. 2 COMPASS/FORTRAN Interface 

Several conventions must be observed when FORTRAN and COMPASS subroutines are inter- 
mixed. For FORTRAN Extended, the conventions are explained in the Fortran Extended 
Version 4 Reference Manual. A brief list follows: 

1. Every COMPASS subroutine shall have: 

a. IDENT and END cards beginning in column 11; 

b. A trace word of the form VFD 42/name, 18/entry address; 

c. An entry point of the form name DATA 0; 

d. An entry point name agreeing with the deck name on the IDENT statement; 

e. Register AO saved on entry and restored upon exit. 

2. Function subroutines shall return single precision values in register X6; 
double precision and complex values are returned in registers X6 and X7. 

3. Subroutine and function calls are performed by a return jump sequence with 
trace information and argument addresses passed through an argument list . 


The form is as 

follows : 


SAl 

ARGLIST 

+ 

RJ 

=X external subprogram name 

- 

VFD 

12 /line number, 18 /trace word address 

ARGLIST 

VFD 

60/ARG1 address 


VFD 

60/ARG2 address 


VFD 

60/ARGM address 


VFD 

60/0 end of argument address list 


Sample parts of a COMPASS subroutine are shown in Figure 2. 



STANDARDS 


IDENT SAMPLE 


^AJ>. 

A 

*P 

* R 

* 0 

* L 

* 0 

* G 

* U 

* E 



ENTRY 

SAMPLE 




TRACE 

VFD 

42/OLSAMPLE 

, 18/SAMPLE 

Trace word 


TEMPAO 

DATA 

0 


Holding location for AO 

EXIT 

SA1 

TEMPAO 


Restore AO 



SAO 

XI 




SAMPLE 

DATA 

0 


Entry point 



SX6 

AO 


Save AO 



SA6 

TEMPAO 





SAO 

A1 


Save input argument 

list 


• * * 



address 



SA1 

ALIST 


Call SUB(A,B,C) 


+ 

RJ 

=XSUB 




- 

VFD 

12/*-TRACE, 

18/TRACE 




SA1 

AO+1 


Fetch 2nd argument 



SA1 

XI 





EQ 

EXIT 

Restore AO and 

return through entry 

point 

ALIST 

VFD 

60/A 

Address of A 




VFD 

60/B 

Address of B 




VFD 

60/c 

Address of C 




VFD 

60/0 

End of argument 

list 


A 

DATA 

0 

Storage for A 



B 

DATA 

0 

Storage for B 



C 

DATA 

0 

Storage for C 




END 






Figure 2. Sample parts of COMPASS routine. 
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2.4 TESTS 

Testing is the activity that takes coded pseudo and FORTRAN statements and removes 
compiler statement errors, input formatting errors, output formatting errors, and program 
structural and logic errors. The testing activity is composed of (1) desk checking, (2) 
component testing, (3) integration testing, and (4) system testing. 

2.4.1 Desk Checking 

Upon completion of coding of the FORTRAN or assembly statements for a module, the 
product should be reviewed with the Chapin chart and the pseudo code for completeness and 
accuracy. The module is compiled and all compiler generated errors are removed to obtain 
an error -free compilation. 

2.4.2 Component Testing 

Component or isolation testing is that activity which takes a module, exercises it 
through its full range of inputs and outputs, and evaluates its performance for any 
necessary correction. Each and every path of a module must be exercised during component 
testing. Stubs for other modules that are referenced must be generated to allow a smooth 
run to completion. 

Standards for component testing will produce tests that will: 

1. exercise typical error free cases, 

2. exercise error free worst case, 

3. produce each error code, 

4. produce variations of errors, 

5. vary all system parameters affecting the module for the above runs, and 

6. vary user options affecting the module for the above runs. 

2.4.3 Integration Testing 

After component testing, the module is integrated into the program. In the figure 
below, all modules designated with I are integrated and the modules designated with N are 


2.4-1 


STANDARDS 


not integrated. A module is never integrated into the program unless it is subordinate to 
a previously integrated module. 



When a module is integrated into the program, integration tests will be performed. 

Integration and testing is the activity wihch places the tested module into the program 
and exercises the module. The module is exercised as thoroughly as possible for inter- 
action with other modules. The tests should check for: 

1. typical case with no errors, 

2. worst case with no errors (checking for efficiency and any designed limits), 

3. each error code, 

4. all possible errors in one entry, 

5. various typical cases, 

6. various system parameters that affect the module, and 

7. various user options that affect the module. 

The test cases and results of integration tests will be documented and saved for 
later use. These test cases can be used to determine if the program is operating as 

designed. » 
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2.4.4 System Tests 

System testing is the activity of exercising the program utilizing all inputs in 
various combinations. According to the concepts of structured programming and top-down 
module integration, as the last module is integrated and tested, testing of the entire 
program will be complete. However, tests will be conducted for. 

1. the ANOPP control statement stream with no errors and composed of 

a. simple sequences, 

b. various typical combinations, and 

c. worst case combinations; 

2. the ANOPP control statement stream with errors, such as, 

a. meaningless input, 

b. no input, 

c. stacked sets of input, and 

d. errors; 

3. all system parameters for 

a. typical settings, 

b. special cases, 

c. worst cases, and 

d. illegal values. 
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2.5 PUBLISHABLE DOCUMENTATION 

2.5.1 Types of Publishable Documentation 

A program of ANOPP f s magnitude requires clear and complete documentation to be of 
value to users and programmers. Engineers and users must understand the available pre- 
diction capabilities and know how to formulate a problem and obtain a solution. Program- 
mers must know how to install, modify, and add to the system. Such documentation will be 
provided in four separate, indexed, stand-alone documents: 

1. Programmer's Manual, 

2. Theoretical Manual, 

3. User's Manual, and 

4. Demonstration Problem Manual. 

2 . 5 . 1 . 1 Programmer* ' s Manual 

The Programmer’s Manual will contain all coding information and specifications for 
the Aircraft Noise Prediction Program. It will be written for use by programmers to 
install, execute, modify, and add modules to the program. As such, it will contain. 

1. a detailed introduction that will describe the concepts and functions of ANOPP; 

2. the standards for design, coding, testing, and program documentation to insure 
compatibility and ease of maintenance; 

3. description of data and tables; 

4. executive, data management, utility, and functional module descriptions, 

5. instructions for installation and operation; 

6. instructions for modification and addition of modules to the system; 

7 „ support program descriptions; and 

8. easily updated index. 

2. 5. 1.2 Theoretical Manual 

The Theoretical (or methods) Manual will provide a concise mathematical description 
of the methods employed in the computational or functional modules. It will describe the 
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analytical or empirical methods and will outline the methods of solution, including all 
implicit and explicit assumptions > limits of use and limits of accuracy. References to 
published material should be included in the text and the index. A user can refer to this 
manual to determine the engineering and mathematical methods that are available in the 
program. 


2. 5.1.3 User t s Manual 

The User’s Manual will be structured to accommodate the needs of different levels of 
users. A user will employ this manual to formulate problems and anticipate results. The 
manual will provide instructions and descriptions for the preparation of problem data and 
explain how to invoke the various options provided for problem solution. The User's 
Manual will thoroughly explain the Executive Control Language and general related capa- 
bilities. 

2. 5.1.4 Demonstration Problem Manual 

The Demonstration Problem Manual will contain detailed descriptions of sample problem 
input and solutions. This manual will be utilized for user education and system valida- 
tion. It will be beneficial to the engineer user and his programming staff. 

2.5.2 Publishable Manual Preparation 

2. 5. 2.1 General 

ANOPP documentation will be typed on 10” x 13” mats that will be supplied by ANOPO. 
These mats will be reduced to 90 percent of their original size during the printing 
process. 

Documents will be prepared using magnetic cards compatible with the equipment avail- 
able to ANOPO, The equipment available to ANOPO is an IBM MAG Card II Typewriter, System 
Model No. 6616; specifications: dual pitch word processing system. 

The magnetic cards of the ANOPP manuals will be furnished to ANOPO with an index to 

facilitate cataloging and filing the cards. 
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Computer printout used in the manuals must be clear and sharp. To ensure this, the 
unlined side of the computer paper should be used and a new ribbon should be inserted on 

the printer. 

To change camera-ready manuscripts, correction tape is preferred over mortising 
(i.e., catting and pasting). Mac, for on.-i.tter corrections, a chalX-iike eahatanc, may 
be used. ERASURES AND OPAQUE WHITE CORRECTION FLUID ARE WOT ACCEPTABEE. 

Minor modifications to pages of published AWOPP documentation will be communicated tc 
ANOPG by means of the Documentation Change Report (DCR). 


The general format of the manuals will be 

1 . Front Cover 

2. Inside Cover Page 

3. Preface 

A. Table of Contents 

5. Page Status Log 

6. Text Body 

7. References 

8. Index 

9. Back Cover 


2. 5.2.2 Spacing 

Doubie-spacing will be used except where groups of a few slngle-sp.eed lines sepa- 
rated by double-spacing for the groups is .or, desirable for clarity or appearance. 

Paragraphs will ba indented S spaces and will be separated from each other by ft 
iines. A line associated with an unnuxbered, underlined explanatory heading -in be 

indented 5 spaces. 

Section and subsection titles will be separated fro. the text (above and below the 
title and from each other) by 3 lines. 
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2. 5. 2. 3 Section Numbering 

Major sections, i.e., those with one number, will be typed with all uppercase letters 
and will be identified with a decimal classification, i.e., one number followed by a 
period, as follows: 

12 . DOCUMENTATION 

Major subsections, i.e., those with two numbers, will be typed with all uppercase 
letters and will be identified with a decimal classification and two numbers, as follows: 

12.2 MANUAL PREPARATION 

Minor subsections, i.e., those with three numbers, will be typed with initial capi- 
tals, underlined, and identified with a decimal classification and three numbers, as 
follows : 

12.2.5 Contents of Manual 

Further subdivision of minor subsections will be typed with initial capitals, will 
not be underlined, and will be identified with a decimal classification and four or more 
numbers, as follows: 

12.2.5.3 Text Printing 

2. 5. 2.4 Page Numbering and Running Headings 

Major subsections will begin at the top of an odd-numbered page. (Odd-numbered pages 
will be printed on the right and even-numbered pages will be printed on the left.) Other 
units such as Data and Table Descriptions should begin at the top of a page where clarity 
or convenience of use is thereby improved. In the case of large major subsections, minor 
subsections may begin at the top of the next page. 

Page numbers will be centered at the bottom of each page. The number will indicate 
the major subsection identifier and page number within the subsection, separated by a 
hyphen. Examples are: 

6 . 1-1 
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6 . 1-2 

6.1- 3 

The numbers of pages changed at a later date will use the format of major subsection 
identifier, hyphen, page number followed by the date of the change (mm/dd/yy), as follows: 

6.1- 1 original page 

6.1-2 (12/09/75) changed page 

Pages inserted at a later date will be identified by the major subsection identifier, 
hyphen, page number, decimal and number followed by the date of the insertion in the form 
(mm/dd/yy), as follows: 

6.1- 1 original page 

6.1-2 (12/09/75) changed page 

6. 1- 2.1 (12/09/75) . added page 

6. 1- 2. 2 (12/09/75) added page 

6.1- 3 original page 

If an odd number of pages is to be inserted, one blank page with a running header and 
a page number should be added to ensure consistency. Such a blank page will contain the 
following sentence: THIS PAGE HAS BEEN LEFT BLANK INTENTIONALLY. 

Pages inserted at a later date between pages of insertions made subsequent to the 
original issue will be identified by the major subsection identification number, hyphen, 
page number, decimal, added page, decimal, inserted page and date as follows: 


6.1-1 

original page 

6.1-2 (12/09/75) 

changed page 

6. 1-2.1 (12/09/75) 

added page 

6. 1-2. 1.1 (01/10/76) 

inserted page 

6. 1-2. 1.2 (01/10/76) 

inserted page 

6.1-2. 2 (12/09/75) 

added page 

6.1-3 

original page 


Running headers, in capitals, will be centered at the top of each page. The major 
section name will be used as the running header on EVEN-NUMBERED PAGES, and the major 
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subsection name will be used as the running header on ODD-NUMBERED PAGES. There is one 
major exception to this rule: for the first page in every major subsection, the major 

section name will be used as the running header. Care must be exercised in determining 
running headers for pages to be inserted. For example, the page to be inserted between 
6.1-3 and 6.1-4 is 6.1-3. 1 and is considered to be an even-numbered page for the purpose 
of determining the running header. The reason for this is that 6. 1-3.1, being printed on 
the back of 6.1-3 (an odd-numbered page), is in effect an even-numbered page. A blank 
"odd-numbered" page, 6. 1-3. 2, with subsection running header and page number must be typed 
to insure consistency. This blank page will contain the following sentence: THIS PAGE 

HAS BEEN LEFT BLANK INTENTIONALLY. 

2 . 5 . 2 . 5 Equations 

Equations will be numbered consecutively beginning with 1 for the first equation in 
each major subsection. References to equations outside a major subsection must refer to 
both the equation number and the major subsection number, i.e. , See Section 5.6, Equation 
12. If the reference is to another manual, the manual name (Theoretical Manual, User's 
Manual, Programmer's Manual) will be given, i.e., See ANOPP Theoretical Manual, Section 
5.6, Equation 12. 

Equations will be centered on the line and separated from the text by three blank 
lines. Equations will be punctuated as part of the text and will be identified at the 
right-hand margin with its Arabic numeral equation number in parenthesis. 

When a group of equations appears in succession without text between them, the 
longest equation will be centered and the equal signs of the remaining equations will be 
aligned with the equal sign of the longest equation. 

The transpose operator for a matrix should be placed outside the brackets (i.e., 

M T is correct; [a T ] is incorrect). The same rule applies to the inverse operation 
(i.e., [A]" 1 is correct ; [a- 1 ] is incorrect). All subscripts for matrices will be 
lowercase letters (i.e., K gg , ). 
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All plus and minus signs in equations will be preceded and followed by one space. 
There will be two spaces before and after all equal signs in equations. There will be no 
spaces between parenthetical expressions. For example: 

( A )( B ) + ( D ) = C 

Equations inserted at a later date will be numbered as decimal parts of the preceding 
equation. For example, two equations inserted between Equation 5 and Equation 6 will be 
designated by Equation 5.1 and Equation 5.2, respectively. For more complicated cases, 
follow the rules given in Section 2. 5. 2. 4 of this document. 

2. 5. 2. 6 Tables, Figures, and References 

Tables and figures will be numbered consecutively beginning with the first table or 
figure in each major subsection. References to tables and figures outside a major subsec- 
tion must refer to both the table or figure number and the major subsection number, i.e.. 
See Section 5.6, Table 2. If the reference is to another manual, the manual name (ANOPP 
Theoretical Manual, ANOPP User's Manual, ANOPP Programmer's Manual) will be given, i.e., 
See ANOPP User's Manual, Section 5.2, Table 2. 

Table titles will be typed with initial capitals. Periods will follow the Arabic 
table number and the end of the complete title as follows: 

Table 3. This Is an Example of a Table Title. 

Figure captions will be typed in lower case letters except for the first letter of 
the first word. Periods will follow the Arabic figure number and the end of the complete 
caption as follows: 

Figure 4. This is an example of a figure caption. 

Single line captions will be centered under the figure, and multiple-line captions will 
be left- justified with the last line centered. 

References will be listed at the end of each major section and will be numbered 
consecutively beginning with 1 for the first reference in each major section. 

Tables, figures, and references inserted at a later date will be designated by a 
decimal and a number. For example, two figures inserted between 


jnumber followed by 

o'r^S ts 




Qci 
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Figure 2 and Figure 3 will be designated Figure 2.1 and Figure 2.2, respectively. 

The words Equation, Figure, Reference, Section, and Table will be spelled out with 
initial capitals when used either in the text or in a caption. The associated Arabic 
numeral will not be enclosed in parentheses. 

2. 5. 2. 7 Capitalization 

Data block names, module names. Data card names, entry point names, and FORTRAN 
variable names will all be capitalized and the letter 0 will be slashed (0). 

Care should be exercised in the use of initial capitals. Formal type names should be 
capitalized throughout the manuals. 

2. 5.2. 8 Punctuation 

Commas will be used to separate the elements in a series and a comma will be placed 
before the final conjunction. 

For punctuation of potential executable statements, punctuation characters should be 
representative of the actual coded statement. 

2.5.3 Changes to Baseline Manuals 

The four ANOPP manuals (Theoretical Manual, User's Manual, Programmer’s Manual, and 
Demonstration Problem Manual), delivered to ANOPO via paper, called mats, and IBM MAG Card 
II compatible magnetic cards, constitute baseline documents. When information in a 
baseline document is added, deleted, or changed, a formal written update to the baseline 
document is required. 

To initiate a change to a baseline document, a Documentation Change Report (DCR) is 
required and must be submitted to the maintenance organization. A DCR is shown in Figure 
1 . 

The report will be reviewed by the maintenance organization and/or ANOPO for appro- 
priateness and extent of change. Changes to manuals can affect software. The results of 
the reviews will consist of comments, required changes, and suggested changes as well as 
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PUBLISHABLE DOCUMENTATION 


DCR No. 


DCR No. 

ANOPP DOCUMENTATION CHANGE REPORT (DCR) 


Originator: _ 
Organization : 


Date: 

Phone No . : 


Manual Theoretical __ . 

User’s _ ? a g e 

Programmer’s Numbers 

Demonstration ___ 

Description and reason of change: 

(Attach a copy of the page(s) to be changed with corrections typed. Use separate pages if 
necessary. ) 


Comments : 


Editor 

Approval 

ANOPP 

Approval 

DPSL 

Entry 

Change 

Made 

ANOPO 
Verif . 

Editor 

Verif. 

DPSL 

Entry 

Date 

Date 

Date 

Date 

Date 

Date 

Date 









Figure 1. ANOPP DOCUMENTATION CHANGE REPORT (DC) 
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rejection or acceptance of the change. If the change is unacceptable, the submitter will 
be so informed and told what action must be taken prior to resubmission. If the change is 
acceptable, the maintenance organization will be informed so the change can be incorpor- 
ated into existing mats and magnetic cards. If the change affects software, a Software 
Change Report (SCR) must be submitted with the DCR. If the change affects more than one 
manual, those manuals and page numbers must be indicated in the COMMENTS of the DCR. 

All changes will be rigidly controlled, reviewed, cataloged, accounted, and filed. 
Documentation Page Status Logs (DPSL) will be maintained for and in each manual. A 
Documentation Change Report Status Log will be maintained with the changes for each 
manual. If a change affects more than one manual, it will be checked on the primary 
Documentation Change Request Report Status Log by the DCR number. 
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3.1 OVERVIEW 

Chapter 3 provides a thorough description of the ANOPP system including labeled 
common blocks, executive control structures, executive data base structures, the Executive 
Management System (EM), Data Base Management System (DBM), Dynamic Storage Management 
System (DSM) , the Update Utility, and other general utilities. 

The Executive Management System controls the execution of ANOPP from beginning to 
end. The Executive Monitor (XM), described in Section 3.5.3, calls into execution the 
eight phases of execution described in Section 3.5.4. The course of execution is de- 
pendent on the control statements found in the Primary Input Stream. A complete descrip- 
tion of these control statements is found in Section 3.5,2. 

The Data Base Management System described in Section 3.6 provides ANOPP with a means 
of storing and retrieving data on sequential and direct access storage devices. DBM 
provides user callable routines for accessing and manipulating the data base structures 
described in Section 3.4. 

The Dynamic Storage Management System described in Section 3.7 provides ANOPP with a 
means of getting and freeing various sized blocks of available core storage and making 
them directly addressable by the requesting module. Many of the core-resident control 
structures described in Section 3.3 are allocated and manipulated via functions of the 
DSM. 

The General Utilities described in Section 3.9 are a collection of general purpose 
subprograms available for usage by all executive system routines. Most of the general 
utility modules are also available for use by functional modules. 

The UPDATE control statement is described under the Executive Management System but 
is explained in more detail in Section 3.8. UPDATE provides a means of building a new 
data unit either from an existing data unit used as a basis for modification or from one 
or more data members on one or more data units . 
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3.2 LABELLED COMMON BLOCKS 

The FORTRAN data structure called labelled common is used in ANOPP implementation for 
reasons of efficiency and security. It is efficient in terms of storage and execution 
time for several modules that require access to a common set of parameters to share them 
in common storage rather than continually passing them as arguments in lengthy calling 
sequences. Security is maintained on a need to know basis by including the labelled 
common statement in only those modules that share the requirements for availability of the 
parameters. 

All of the labelled common blocks used by the ANOPP executive system are described in 
the following sections in terms of their primary purpose followed by a list of modules 
that reference them. 

3.2.1 /XBSC/ 

Common block /XBSC/ contains those variables used during the Initialization Phase by 
XBS to initialize various executive system tables. For further description of the vari- 
ables in /XBSC/, see the prologue of Block Data XBSCBD. 

Those Executive Modules which use /XBSC/ are: 

XBS XBSCBD XFMANT 

3.2.2 /XCAC L 

Common block /XCAC/ contains variables used during the Secondary Edit Phase by XCA, 
For further description of the variables in /XCAC/, see the prologue of Block Data XCACBD, 

Those Executive Modules which use /XCAC/ are: 

XCA XCABD XCABST XCACL0 XCAI XCAMST 

XCAMXX XCANCS XCANS XCANWC 

3.2.3 /XCRC/ 

Common block /XCRC/ contains those variables used by XCR, the executive crack module. 
For further description of the variables in /XCRC/, see the prologue of Block Data XCRCBD. 
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Those Executive Modules which use /XCRC/ are: 


XCR 

XCRCBD 

XCRCH 

XCAD0T 

XCRDR 

XCREF 

XCREXP 

XCRFC 

XCRILL 

XCRPD 

XCRPH 

XCRPN 

XCRP0T 

XCRREN 

XCRSEN 

XCRSNM 

XCRWC 

XCRWCH 


3.2.4 /XCS / 

Common block /XCS/ contains those variables used in processing or building control 
statement records. For further description of the variables in /XCS/, see the prologue of 
Block Data XCSBD. 


Those Executive Modules which use /XCS/ are: 


XAR 

XAT 

XBS 

XBSDBM 

XBSDSM 

XBSBCS 

XCSBD 

XCSIL 

XCSL0G 

XCSP 

XCSPM 

XCSSL 

XCT 

XDT 

XEX 

XEXA 

XEXL 

XFM ■ 

XFMANT 

XG0 

XIF 

XLINK 

XMERR 

XMERRI 

XMERRL 

XPA 

XPAVTB 

XPU 

XPUTP 

XRT 

XRTAMU 

XRTBAD 

XRRBCS 

XRTBLR 

XRTCAL 

XRTCSS 

XRTDAT 

XRTI 

XRTLRF 

XRTLSE 

XRTSER 

XRTSEX 

XRTSIF 

XRTSSS 

XRTSYN 

XRTU 

XRTVCS 

XSS 

XTB 

XUN 

XUPADS 

XUPCS 

XUPDIR 

XUPSRC 


XUPSYN 

3.2.5 /XCSFM/ 


Common block /XCSFM/ contains those parameters used by the Executive System Modules, 
including those which maintain interface functions between the control statement stream 
and the functional module. For further description of the variables in /XCSFM/, see the 
prologue of Block Data XCSFMBD. 


Those Executive Modules which use /XCSFM/ are: 


XASKP 

XBS 

XCSST 

XEX 

XIF 

XPA 

XPLINE 

XPUTP 


XBSSP XBSTP 

XEXA XFAN 

XPAGE XPAVTB 


XCSFMBD XCSP 
XFMANT XGETP 

XPLAB XPLABQ 
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3.2.6 /XCSPC/ 


Common block /XCSPC/ contains those variables during the Control Statement Processing 
Phase by XCSP. For futher descriptions of the variables in /XCSPC/, see the prologue of 
Block Data XCSPCBD. 


Those Executive Modules which use /XCSPC/ are: 


XAR 

XAT 

XCSIL 

XCSL0G 

XCSP 

XCSPBD 

XCSPM 

XCSSL 

XCT 

XDR 

XDT 

XEX 

XEXA 

XEXL 

XG0 

XIF 

XMERR 

XMERRI 

XMERRL 

XPA 

XPU 

XSS 

XTB 

XUN 

XUPCS 

XUPLST 

XUPNEW 

XUPSRC 




3.2.7 /XCVT/ 

Common block /XCVT/ contains general variables used by various Executive System 


Modules. For further description of the variables in /XCVT/, see the prologue of Block 
Data XCVTBD . 


Those Executive Modules which use /XCVT/ are: 


DSMERR 

ILSHFT 

IMASK 

MMBFSI 

MMBFST 

MMBFT8 

MMPFMT 

MMSAND 

MMSUD 

NUMTYP 

NWDTYP 

TMCL0S 

TMSTD 

TMT0PN 

XAR 

XBSDBM 

XBSDSM 

XBSGCS 

XCA 

XCABST 

XCAT 

XCANS 

XCANSP 

XCANWC 

XCRCH 

XCRD0T 

XCRDR 

XCRPH 

XCRPN 

XCRP0T 

XCRWCH 

XCSCCS 

XCSCIL 

XCT 

XCDBDU 

XCDBMD 

XDT 

XEX 

XEXA 

XFMANT 

XFMDSM 

XFMMM 

XM 

XMERR 

XMERRI 

XPAVTB 

XPK 

XPKM 

XRT 

XRTBAD 

XRTBCS 

XRTI 

XRTLRF 

XRT0BD 

XRTU 

XRTVCS 

XST0RE 

XT1AL 

XT1FV 

XT2AL 

XT3LK 

XUN 

XUNALL 

XUNPK 

XUNPKM 

XUP 

XUPCDT 

XUPCGP 

XUPCHG 

XUPCIN 

XUPC0S 

XUPCRY 

XUPDIR 

XUPECE 

XU PEC I 

XUP0MS 

XUP0MT 

XUPPRE 

XUPXCR 

XUPXFR 

XVNAME 


IKSHFT 

ISHIFT 

MMBAME 

MMCL0S 

MMCLSE 

MMGED 

MMUHMD 

MMUPMD 

MMVTD 

TMEDTB 

TMFTE 

TMM0PN 

XASKP 

XAT 

XBS 

XBSIN 

XBSSP 

XBSTP 

XCAMST 

XCAMXX 

XCANCS 

XCATRA 

XCR 

XCRCF 

XCRFC 

XCRILL 

XCRPD 

XCRPS 

XCRSRD 

XCRWC 

XCSP 

XCSPM 

XCSST 

XCTDU 

XCUTBD 

XDR 

XFAN 

XFETCH 

XFM 

XFMTM 

XGETP 

XIF 

XMPRT 

XPA 

XPAGE 

XPU 

XPUTP 

XRE 

XRTBLR 

XRTCAL 

XRTEND 

XRTPIN 

XRTSIF 

XRTSYN 

XTB 

XTBERR 

XTRACE 

XT3FL 

XT3FV 

XT3IF 

XUNBGN 

XUNCCS 

XUNLUH 

XUPADD 

XUP ADS 

XUPALL 

XUPCHI 

XUPCHS 

XUPCHX 

XUPCQD 

XUPCQT 

XUPCS 

XUPINS 

XUPNEW 

XUPNMT 

XUPSRC 

XUP SUM 

XUPSYN 
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3.2.8 /XDBMC/ 

Common block /XDBMC/ contains those variables used by the Data Base Management 
System (DBM). For further description of the variables in /XDBMC/, see the prologue of 
Block Data XDBMCBD. 

The Executive Modules which use /XDBMC/ are: 


MMBAME 

MMBFSI 

MMBFST 

MMBFT1 

MMBFTB 

MMBFT9 

MMBMCI 

MMBMH 

MMCL0S 

MMCLSE 

MMCRMX 

MMD0MC 

MMEDNM 

MMERR 

MMFEFB 

MMGED 

MMGEFB 

MMGET 

MMGETE 

MMGETR 

MMGETW 

MMGNEW 

MMGNWE 

MMI0MC 

MMMDMH 

MMNWR 

MM0PRD 

MM0PWD 

MM0PWS 

MMPFWT 

MMP0SN 

MMPUT 

MMPUTE 

MMPUTR 

MMPUTW 

MMREW 

MMRMD 

MMRMH 

MMRRS 

MMSAMD 

MMSFEI 

MMSKIP 

MMSUD 

MMUHMD 

MMUPMD 

MMVBA 

MMVNM 

MMVUM 

XAR 

XAT 

XBSDBM 

XCT 

XCTBDU 

XCTBMD 

XCTDU 

XDBMCBD 

XDR 

XDT 

XFMMM 

XFMTQ 

XPU 

XUN 

XUNALL 

XUNBGN 

XUNCCS 

XUKCPY 

XUPADD 

XUPXFR 

XUPALL 

XUPCGP 

XUPCHG 

XUPNEW 

XUPXCR 


3.2.9 /XDSMC/ 


Common block /XDSMC/ contains variables required by the Dynamic Storage Management 
System (DSM). For further description of the variables in /XDSMC/, see the prologue of 
Block Data XDSMCBD. 


Those Executive Modules which use /XDSMC/ are: 


DSMB DSMC0N DSMDFB DSMERR DSMET DSMEUX 

DSMF DSMFLB DSMG DSMGUB DSMI DSMIDS 

DSML DSMQ DSMR DSMS DSMU DSMX 

DSMXFB DSMIST XDSMCBD XFMDSM 


3.2.10 /XDTMC/ 


Common block /XDTMC/ contains variables required by the Table Manager Module. For 
further description of the variables in /XDTMC/, see the prologue of Block Data XDTMCBD . 

Those Executive Modules which use /XDTMC/ are: 


TMBLD1 TMCL0S TMEDTB TMERR TMFTE TMGEN1 
TMM0PN TM0PN TM0PNA TMSTD TMTABP TMTERP 
TMT0PN XBSDBM XDTMCBD XFMTM XTB XTBADV 
XTBAIV XTBLD1 XTBPNC XTBVAR 
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3.2.11 /XP0TH/ 


Common block /XP0TH/ contains those variables used by the module XCRP0T and its 
submodules. For further description of the variables in /XP0TH/, see the prologue of 
Block Data XP0THBD. 


Those Executive Modules which use /XP0TH/ are: 


XCRD0T XCRDR XCREXP XCRFC XCRFH XCRP0T 

XCRSRD XCRWCH XP0THBD 


3.2.12 /XR00T/ 


Common block /XR00T/ contains those variables used during the Primary Edit Phase by 
XRT. For further description of the variables in /XR00T/, see the prologue of Block Data 
XR00TBD. 


Those Executive Modules which use /XR00T/ are: 


XR00TBD XRT 

XRTCSS XRTDAT 

XRTLSE XRTPIN 

XRTSSS XRTSYN 


XRTBAD XRTBCS 

XRTEND XRTI 

XRTRS XRTSER 

XRTTC XRTU 


XRTBLR XRTCAL 
XRTLRF XRTLSA 
XRTSEX XRTSIF 


3.2.13 /XSLF/ 

Common block /XSLF/ contains those variables used in creating and using sequential 
library files. For further description of the variables in /XSLF/, see the prologue of 
Block Data XSLFBD. 


Those Executive Modules which use /XSLF/ are: 

XSLFBD XUN XUNALL XUNBGN XUNCCS XUNCPY 

XUNEND XUNLUH 


3.2.14 /XSPT/ 


Common block /XSPT/ contains those Executive System Parameters which may be set by 
the user via a SETSYS control statement. For further description of the variables in 
/XSPT/, see the prologue of Block Data XSPTBD. 
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Those Executive Modules which use /XSPT/ are: 


XBS XBSSP XCA 
XCSP XMERR XRT 
XSPTBD XSS 


XCAMXX XCANCS XCANWC 

XRTDAT XRTEND XRTPIN 


3.2.15 /XUPC/ 


Common block /XUPC/ contains those variables used by the UPDATE modules (XUP). For 
further description of the variables in /XUPC/, see the prologue of Block Data XUPCBD. 

Those Executive Modules which use /XUPC/ are: 


XUP XUPADD 
XUPCHG XUPCHI 
XUPCPY XUPCQD 
XUPLST XUPMLV 
XUP0ST XUPPRE 
XUPXCR XUPXFR 


XUPADS XU PALL 

XUPCHS XUPCHX 

XUPCQT XUPCS 

XUPNEW XUPNMT 

XUPRLV XUPSRC 


XUPCDT 

XUPCGP 

XUPC IN 

XUPC0S 

XUPDIR 

XUPINS 

XUP0MS 

XUP0MT 

XUPSUM 

XUPSYN 
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3.3 EXECUTIVE CONTROL STRUCTURES 

This section includes a graphical layout and a usage description of all primary 
control structures used and referenced by executive modules. A control structure is a 
table, a directory or any other information block which is core resident and not residing 
on a data unit /member. An information block which is both core resident and data unit/mem- 
ber resident is classified as a data base structure and is included in Section 3.4. 

These control structures residing in core are generally addressable in two ways; 
either as indexed arrays from 1 to n , or as a block of dynamic storage indexed relative to 
the FORTRAN variable IX in system labelled common block /XAN0PP/ plus a positional offset 
from the start of the block. The dynamic storage index is referred to generically in this 
manual as the IDX of the block. See the following example which addresses the array TBL 
from 1 to n or correspondingly the block IX(IDXTBL) plus 0 to n-1. 

TBL(l) IX( IDXTBL+O ) 

TBL( 2 ) IX( IDXTBL+1 ) 

TBL( 3 ) IX( IDXTBL+2) 

TBL(n) IX(IDXTBLtn-l) 

The positional offset constants 0 to n-1 have been parameterized by using FORTRAN 
variables containing constant values to reference offset table entries in many of the 
ANOPP executive control structures. 

3.3.1 System Table Types 

Many of the tables and directories maintained by ANOPP system modules have a common 
structure. This structure has two parts, a preface and a body. The preface describes the 
table's current status and the body contains the entries, which may be fixed or variable 
length depending on the particular table definition. A table which has this common struc- 
ture is designated as a System Table. Executive Utilities are available for performing 
various functions for a System Table. 
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There are three types of System Tables. The structure of the three types are de- 
scribed below. 

3. 3.1.1 System Table Type 1 

Description: The System Table Type 1 structure provides for fixed length table 

entries. Each entry made in the table requires the same number of words. The positions 
of words in the preface and the first word beyond the preface have been parameterized by 
variables in the common block /XCVT/. 


Format : 


Preface 


Body 


Position 


System Table Type 1 


name 


nae 


nee 


le 


entry. 


entry 


entry 


nee 


entry 


nae 


Parameter 


NTNAME 

NTMAk 

NTCUR 

NTENT 

NTSTRT 


not used currently 


Common 

Block 


/XCVT/ 


name 

nae 

nee 

le 

entry^ 


name of table (Hollerith) 
number of allocated entries (integer) 
number of current entries (integer) 
length of an entry in words (integer) 
an entry of length le 
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The total length of a type 1 table is the sum of preface length and body length where 
body length is the product of the number of allocated entries and the length of an entry. 
For a type 1 table in dynamic storage at IDXT1 , the expression for its length, LENT1, 
would be: 

LENT1 = NTSTRT + IX( IDXT1+NTMAX )*IX( IDXT1+NTENT) 


3. 3.1. 2 System Table Type 2 

Description : The System Table Type 2 structure provides for variable length table 

entries. The number of words required for an entry is not necessarily the same as any or 
all of the other table entries. The user of this table structure must devise his own plan 
to access the individual entries in the table, if there is more than one entry in the 
table. The positions in the preface and the first word beyond the preface have been 
parameterized similar to type I tables with the exception of the fixed length of an entry 
which has no meaning for type 2 tables. 


Format : 


Preface 


Body 


name 

naw 

new 

entry^ 


System Table Type 2 


Position 

Parameter 



name 


naw 


new 


not used 

r 

entry^ 


• 


entry^ 


• 


NTNAME 

NTMAX 

NTCUR 


NTSTRT 


name of table (Hollerith) 

number of allocated words in body (integer) 
number of current words in body (integer) 
an entry of variable length 


Common 

Block 


/XCVT/ 
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The total length of a type 2 table is the sum of preface length and body length where 
body length is the number of allocated words. For a type 2 table in dynamic storage at 
IDXT2 , the expression for its length, LENT2, would be: 

LENT2 = NTSTRT + IX ( IDXT2+NTMAX ) 

3. 3,1.3 System Table Type 3 

Description : The System Table Type 3 is characterized by forward chained, fixed 

length entries. These entries are linked into one of three chains — the used entry 
chain, the free entry chain, or the other entry chain. Each entry contains a chain 
control word, which serves as a forward pointer to its successor in the chain, followed by 
space reserved for the user's entry data. A chain control word whose value is zero 
indicates the end of the chain. Each position in the preface plus the first word of the 
first entry have been parameterized by variables in common block /XCVT/. 

Free entries may exist anywhere in the body of the table, not necessarily the last 
entry. The table can accommodate up to three chains. 

Format : 

Position Common 

Parameter Block 

NTNAME /XCVT/ 

NTMAX 
NTCUR 
NTENT 
NT3USD 
NT3FRE 
NT30TR 

NT3STR 


System Table Type 3 


Preface 


name 

nae 

ctl 

le 

uecp 

fecp 

oecp 

entry^ 

• 

entry^ 

* 

entry 

-'nae 


Body 




EXECUTIVE CONTROL STRUCTURES 


name 

nae 

ctl 

le 

uecp 

fecp 

oecp 

entry^ 


name of table (Hollerith) 
number of allocated entries (integer) 
current table length in words (integer) 
length of an entry (integer) 

used entry chain pointer index to the first entry in the used 
entry chain 

free entry chain pointer index to the first entry in the free 
entry chain 

other entry chain pointer index to the first entry in the other 
entry chain 

entry of length le including the chain control word 


The total length of a type 3 table is the sum of preface length and body length where 
body length is the product of the number of allocated entries and the length of an entry. 
For a type 1 table in dynamic storage at IDXT3, the expression for its length, LENT3, 
would be: 

LENT 3 = NT3STR + IX ( IDXT3+NTMAX )*IX( IDXT 3+NTENT ) 
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3.3,2 Active Member Directory (AMD) 


System Table Type : 3 

Residence : Global Dynamic core; the IDX is IDXAMD in /XDBMC/ common block. 

Primary Users . Data Member Manager and Data Table Manager open and close routines 
(MM0PRD, MM0PWD , MM0PWS, MMCL0S , TM0PN, and TM0PNA) and XFMMM which logically closes 
active members that remained open following termination of a functional module. 


Description : The AMD is a table identifying all data members which are open to Data 

Member Manager (MM) and provides a linkage to the NAME argument used to open a data member 
and to the Data Unit Directory entry for the data unit named in the open member request. 
Additionally, an AMD entry indicates whether a data member is open for input, output, or 
both, and if open for output, whether it is open for direct or indirect writing. 


The AMD is allocated during ANOPP initialization and remains resident throughout an 
ANOPP run. Expansion of the AMD occurs as required. 

Format : 

Position Common 

Active Member Directory Parameter Block 


(see system table type 3 
preface) 


IAMDMN /XDBMC/ 

IAMUDP 

IAMDWF 

IAM0RD 

IAM0WR 


Preface 


entry^ 


entry . 


Body 


entry 


nae 


name 

nae 

ctl 

le 

uecp 

fecp 

oecp 

entry 

data 

* 

ccw 

dmn 

ud p 

dwf 

ord 

owr 

* 

entry 

data 


3.3-6 




EXECUTIVE CONTROL STRUCTURES 


ccw - chain control word linking the entry into the free or used chain 
Other chain is invalid for the AMD. 
dmn - data member name (Hollerith) 

udp - Data Unit Directory entry pointer which is an index relative to 
the beginning of the DUD 
dwf - direct write flag 

ord - open read control word which contains the IDX of the NAME array 
used if the data member was opened for reading via MM0PRD 
owr - open write control word which contains the IDX of the NAME array 

used if the data member was opened for writing via MM0PWD or MM0PWS 


Initialization : During ANOPP initialization XBSDBM creates the AMD using the follow- 

ing variables: 

1. The number of words of dynamic core initially allocated is determined using 
the following formula: 

LEN = NT3STR + N AEAMD* LENAME 

NT3STR is a variable from /XCVT / common block, and NAEAMD and LENAME are from 
/XDBMC/ common block. 

2. The AMD table preface is initialized as follows: 

name = IDAMD from /XDBMC/ common block 

nae = NAEAMD from /XDBMC/ common block 

ctl = LEN which was computed in 1. above 

le = LENAME from /XDBMC/ common block 

uecp - zero 

fecp = NT3STR+1 

oecp = zero 

3. The body of the AMD is initialized in system table type 3 format using sub- 
program XT3IF. 

Entry : An entry is made in the AMD each time a previously unopened data member is 

opened via MM0PRD, MM0PWD, or MM0PWS . 

Retrieval : The AMD used entry chain is searched each time a request to 
member occurs. If a matching entry is found and it is not open for the mode 
the open request, the entry is updated according to the mode (read or write) 
request. 

The AMD is also searched by Data Table Manager when a data table is being opened to 
prevent a data member from being open to both Data Member Manager and Data Table Manager. 


open a data 
specified by 
of the open 


om<< 
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Deletion : When a data member is closed for both input and output processing modes, 

its AMD entry is cleared and linked into the free entry chain. 
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3.3.3 Alternate Names Table (ANT) 


System Table Type : 1 

Residence : Global dynamic core; the IDX is LANT in /XCSFM/ common block. 

Primary Users : Data Member Manager, Data Table Manager, and the Parameter Main- 

tenance Functions (XASKP, XPUTP, XGETP). 

Description : The ANT is a table of reference names and corresponding alternate names 

as specified on the EXECUTE CS. Alternate names exist only during the F.M. Processing 
Phase when the specified F.M. is executed; at other times, the ANT is a null table. 


Format : 


Alternate Names Table 


Preface 


entry. 


Body 


entry 


name 


nee 


le 


refname 


altname 


refname 


altname 


nee 


nee 


Position Common 

Parameter Block 


(see System Table Type 1 
Preface ) 


LANTN /XCSFM/ 

LANTA 


refname - reference name specified on EXECUTE CS (Hollerith) 

altname - corresponding alternate name specified on EXECUTE CS (Hollerith) 


Initialization : ANT is allocated for zero entries during the Initialization Phase 

(XBS) and is reinitialized for zero entries upon completion of the Functional Module 
Processing Phase. 

1. The number of words of dynamic core initially allocated is determined by: 

LEN = NTSTRT 

NTSTRT is a variable from /XCVT/ common block. 
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2. The ANT preface is initialized as follows: 

name = NAMANT from /XBSC/ common block 

nae = NAEANT from /XBSC/ common block 

nee = NCEANT from /XBSC/ common block 

le = LEANT from /XBSC/ common block 

Entry : When an EXECUTE control statement is processed during Control Statement 

Processing Phase, the ANT is allocated in GDS for exact number of entries required. An 
entry for each reference/alternate name specified is made and the values for nae and nee 
are updated. 

Retrieval : Utility XFAN (fetch alternate name) provides retrieval. MM and TM user 

calls and the utilities XPUTP, XASKP, and XGETP retrieve alternate names automatically On 
each call. 

Deletion : All entries deleted upon completion of the functional module specified on 

the EXECUTE control statement by the XFMANT module. 
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3.3.4 Data Table Directory (DTD) 

System Table Type : 3 

Residence : Global dynamic core; the IDX is IDXTD in /XDTMC/ common block. 

Primary Users : Data Member Manager and Data Table Manager open and close modules 

(MM0PRD, MM0PWD , MM0PWS, TM0PN , TM0PNA, TMCL0S ) and XFMTM which logically closes data 
tables left open following termination of a functional module. 

Description : The DTD identifies all data tables, both open and closed, which are 

core resident at any point in time during an ANOPP run. A DTD entry contains a data unit 
and data member name, which uniquely identify a data table, and an IDX variable which is 
used in the following two ways: 

1. When a data table is open, the IDX variable contains the IDX to the NAME 
argument used in opening the table and the third word of the NAME argument 
contains the IDX to the data table. 

2. When a data table is closed, the IDX variable contains the IDX to the 
data table. 

The DTD is allocated during ANOPP initialization by XBSDBM and remains resident until 
the ANOPP run completes. The DTD cannot be expanded dynamically and therefore ANOPP will 
terminate abnormally if the user tries to simultaneously open more data tables than there 


are entries in the DTD. 
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Format : 


Preface 


f 


Data Table Directory 


entry a 


Body 


entry^. 


entry. 


nae 


name 

nae 

ctl 

le ! 

oecp 

fecp 

cecp 

entry 

data 

• 

ccw 

dun 

dmn 

idx 

• 

entry 

data 


Position Common 

Parameter Block 


(See System Table Type 3 
Preface ) 


ITEDUN /XDTMC/ 

ITEDMN 

ITEIDX 


°ecp - open entry chain pointer index to the first entry in the open entry chain 
fecp - free entry chain pointer index to the first entry in the free entry chain 
cecp - closed entry chain pointer index to the first entry in the closed entry 
chain 

There are three entry chains in the body of the DTD; the "open" entry chain, the 
free entry chain, and the "closed" entry chain. Entries in the open entry chain contain 
the following entry data: 


ccw - chain control word linking the entry into the open chain 
dun - name of the data unit on which the data table resides 
dmn - name of the data member which contains the data table 
idx - index, relative to /XAN0PP/ common block, of the NAME argument 
used in opening the data table 

Entries m the free entry chain have only a chain control word and the entry data is 


zero. 
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Entries in the closed entry chain contain the following entry data: 

ccw - chain control word linking the entry into the closed entry chain 
dun - as described previously 
dmn - as described previously 

idx - index, relative to /XAN0PP/ common block, of the data table which 
is located in global dynamic core 

Initialization : During ANOPP initialization, XBSDBM creates the DTD using the 

following : 

1. The number of words of dynamic core initially allocated is determined using 
the following formula: 

LEN = NT3STR + NAETD * LENTDE , where 
NT3STR is a varible from /XCVT/ common block, and NAETD and LENTDE are from 
/XDTMC/ common block. 

2. The DTD preface is initialized as follows: 

name = from IDTD in /XDTMC/ common block 

nae = from NAETD in /XDTMC/ common block 

ctl = from LEN computed in 1. above 

le r from LENTDE in /XDTMC/ common block 

oecp = 0 

fecp = 1 + NT3STR 

cecp = 0 

Entry : A new entry is made in the DTD when a data table which is not currently in 

the open entry chain or the closed entry chain is opened. 

Retrieval : Entries are retrieved from both the open and closed entry chains by Data 
Table Manager (DTM) open and close modules. The DTM open data table modules (TM0PN, 
TM0PNA) link DTD entries from the closed entry chain into the open entry chain and the 
close data table module (TMCL0S) links from the open to the closed entry chain. 

Deletion: Data Member Manager (DMM) open data member modules (MM0PRD , MM0PWD , and 

MM0PWS) also search the open and closed entry chains in the DTD for a data table residing 
on a particular data unit and member. However, if DMM finds an entry, either the DMM 
module involved abnormally terminates ANOPP if the entry is in the open entry chain or it 
frees the data table from core and links the DTD entry from the closed to the free entry 
chain. 
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3.3.5 Data Unit Directory (DUD) 

System Table Type : 3 

Residence : Global dynamic core; the IDX is IDXUD in /XDBMC/ common block. 

Primary Users : All DBM control statements, the UPDATE control statement, all Data 

Member Manager modules, and Data Table Manager open data table modules. 

Description : The DUD identifies all data units which are available to ANOPP at any 

one time during ANOPP execution. A DUD entry contains a copy of the data unit header for 
the unit, an IDX linking the entry to the external file information table and buffer, and 
other identification and control information. 

The DUD is allocated during ANOPP initialization by subprogram XBSDBM and remains 
resident until ANOPP termination. The DUD must be one of the control structures allocated 
at the beginning of global dynamic core and may not be expanded. This insures that the 
DUD does not move during DSM consolidation of global dynamic core. 
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Format : 



Position Common 

Parameter Block 


(See System Table Type 3 
Preface) 


IUHID /XDBMC/ 

Data Chart iuhAF 

Header IUHNWA 

. IUHMDA 

IUHMDL 
IDUDUP 
IDUEFN 
Data Unit IDUCBI 

Control mUPBI 

Info. IDUOMC 

IDUDWF 


entry data: 

ccw - chain control word linking the entry into the free or used chain. 

The other chain is invalid in DUD. 
id - Data Unit Header identifier (Hollerith) 

af - integer ARCHIVE flag, if equal to zero, write is permitted on the 
data unit. If equal to 1, then writing is not permitted, 
nwa - integer next word address that is available for writing on the data 
unit 

wa - integer word address of the Data Member Directory on the data unit 
len - integer length (in words) of the Data Member Directory 
dun - data unit names used for the data unit in the current ANOPP run 
efn - external file name assigned to the data unit by the operating system 
cbi - the IDX to the external file information and buffer in global dynamic 
core 

pbi - the "previous buffer index" contains the value of cbi from the previous 
I/O operation. It is used to determine if the IDX to the buffer has 
been changed since the last I/O operation 
omc - integer open member count; indicating the number of data members 
currently open on the data unit 
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dwf - integer direct write flag which indicates that a data member is open 
to write directly on the unit 

Initialization : During ANOPP initialization, subprogram XBSDBM creates the DUD using 

the following : 

1. The number of words of dynamic core initially allocated is determined using 
the formula: 

LEN = NT3STR + NAEUD * LENUDE, where 
NT3STR is a variable from /XCVT/ common block, and NAEUD and LENUDE are from 
/XBDMC/ common block. 

2. The DUD preface is initialized as follows: 

name = from I DUD in /XDBMC/ common block 
nae = from NAEUD in /XDBMC/ common block 
ctl = from LEN computed in 1. above 
le = from LENUDE in /XDBMC/ common block 
uecp = 0 

fecp = NT3STR * 1 
oecp = 0 

3. The body of the DUD is initialized using subprogram XT3IF which builds the 
free entry chain. 

Entry : A new entry is made in the DUD whenever a CREATE, ATTACH, or L0AD control 

statement is processed. Also, use of Data Member Manager's (DMM) open for indirect 
writing facility causes creation of a temporary entry in the DUD for each data member 
opened. 

Retrieval : The DUD is searched each time a DBM control statement, an UPDATE or a 

Data Table Manager open or close request is processed. Also, when a data member is open 
indexes to the related DUD entry (or entries if open for indirect write) are retained in 
the member's AMD entry and MCB. These indexes are used to directly access the DUD entry 
for all DMM input and output processing. 

Deletion : Entries are deleted from the DUD by the DETACH and PURGE control state- 

ments, and, when a data member which was open for indirect writing is closed, its temporary 
(scratch) data unit is purged and the DUD entry is deleted. 
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3.3.6 Member Control Block (MCB) 


System Table Type : Not applicable 

Residence : Global dynamic core; the IDX is the third word of the NAME argument used 

in opening the data member. 

Primary Users : Data Member Manager Modules. 

Description : The MCB is the primary control structure used in building and accessing 

data members. It provides indexes to the Data Unit Directory and Active Memory Directory 
entries which relate to the data member and control information regarding current record 
being read or written and position within record. In addition, it contains the Data 
Member Header, Record Directory, and one Record Subdirectory, 

The MCB is allocated when a data member is opened and is resident until the member is 
closed. Reallocation of the MCB takes place only when opening a data member for reading. 
Expansion is required then to provide space for a Record Subdirectory. 


Format : 


Member 

Control 

Information 


Data 

Member 

Header 

Record 

Subdirectory 


id 

len 

indud 

inamd 

inrd 

inrs 

crn 

rwc 

infst _ 

wadmh 

(see Data Base 
Structures ) 

(see Data Base 
Structures ) 


The MCB consists of three separate structures which are necessary to control member 


data input and output: 

1. Member Control Information (MCI) 

2. Data Member Header (DMH), and 

3. Record Subdirectory (RS). 
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Since the DMH and RS are discussed in the Data Base Structures section, only the MCI 
is described here. 


MCI: 


id 
len 
in dud 

inamd 

inrd 

inrs 

crn 

rwc 

infst 

wadmh 


MCB identifier (Hollerith) 
integer length (in words) of the MCB 

index, relative to the beginning of the DUD, to the DUD entry 
describing the data unit to which the data member belongs 
index, relative to the beginning of the AMD, to the AMD entry 
for the data member described by the MCB 

index, relative to the beginning of the Master Record Directory 
(RD), to the RD entry for the Record Subdirectory (RS) current 
in the MCB 

index, relative to the beginning of the RS, to the RS entry for 
the current data record 

integer current record number; MMSKIP and MMP0SN modify this field 
to provide random accessing of data 

record word count; this field is used to determine the current 
position within a record for partial record gets and puts. It 
contains the count of the number of words transferred to or from 
a record 

FST index is used for element gets and puts (MMGETE and MMPUTE ) to 
retrieve element type and length from the Format Specification Table 
(FST) in the DMH 

integer word address of the DMH, provides MMCL0S with the address 
at which the DMH is to be written if the member is open to write, 
or zero if its open to read 


Initialization : Not applicable 

Entry : Not applicable 

Retrieval : The MCB is accessed and modified during every DMM operation. 

Deletion : Not applicable 
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3.3.7 Member Description Blocks Table (MDBT) 


System Table Type : 3 

Residence: Global dynamic storage; the IDX is MXMDB in /XCS/ common block. 

Primary Users: XRT module (Primary Edit Phase) to initialize an entry for an Mxxx 

name assigned corresponding to a CALL control statement. XRT also constructs the M001 
member and puts the MDB in executable format. 

XCA module (Secondary Edit Phase) to initialize entries as Mxxx names are assigned 
and to construct the Mxxx for the CALL being executed and put the corresponding MDB in 
executable format. 


Description : Contains a Member Description Block (MDB) entry for each Mxxx type data 

member for which an Mxxx name has been assigned. Each entry contains pertinent informa- 
tion about the member, such as member name, number of current CS record in execution, Mxxx 
that called this Mxxx, maximum length of a CS record, length of label record. The MDB 
settings indicate if the Mxxx member has been constructed and exists on XSUNIT. 


Format: 


Member Description Blocks 
Table 


Position Common 

Parameter Block 


Preface 


Body 



(See system table type 
1 Preface) 


MNAME 

JCUR 

MCALL 

MRL 

MLL 


/XCS/ 
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entry data: 

First entry: 

nm - MO 01 - name of root member (Hollerith) 
cr - number of current CS record in execution 

ell - entry not applicable to M001 
csrl - maximum length of a CS record for M001 
lrl - number of words in label record for M001 

Subsequent entries: 

nm - name of' Mxxx data member (Hollerith) 
cr - number of current CS record in execution 

ell - name of Mxxx data member that called this Mxxx member in current 
execution 

csrl - maximum length of a CS record for Mxxx 
lrl - number of words in label record for Mxxx 

Initialization : The MDBT is allocated and the MDB entry for the M001 member Is 


initialized by XBS. 


1. The number of words of dynamic core initially allocated is determined using 
the formula: 

NWDS = LPREF + NAEMDB * LEMDB , where 
LPREF , NAEMDB, LEMDB are in /XBSC/ common block. 

2. The MDBT is initialized as follows: 

name = NAMMDB from /XBSC/ common block 

nae = NAEMDB from /XBSC/ common block 

nee = NCEMDB from /XBSC/ common block 

le = LEMDB from /XBSC/ common block 

entry ^ : 

nm = NM001 from /XBSC/ common block 

cr =0 

ell = blank 

csrl = 0 

lrl = 0 


Entry : The M001 MDB entry is put into executable format during the Primary Edit 

Phase by XRT. The csrl and lrl values are entered for M001 by XRT when M001 is built. 
Member Description Block entries for other Mxxx members are added to the MDBT as Mxxx 
member names are assigned during the Primary and Secondary Edit Phase whenever a CALL 
control statement is edited. When the MDB is added, nm is defined as the Mxxx name 
assigned, ell the Mxxx calling member, and all other entries are set to zero (entry put 
into initialized format). The csrl and lrl values will be entered in the MDB (entry put 
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into executable format) the first time the CALL control statement is executed since the 
Mxxx member is built on the first execution. 

Retrieval : Upon entry to the CS Processing Phase (XCSP), the maximum CS record 

length and label record length are retrieved from the MDB for the Mxxx member in current 
execution. These lengths are used to allocate LDS blocks for storing CS records and the 
label record for the Mxxx in current execution. XCSP also retrieves the number of the 
current CS record in execution from the MDB for the Mxxx in current execution, and uses 
that value in positioning to the next CS record to be executed. Upon completion of 
execution of an Mxxx member, XRE processes the RETURN CS and redefines the Mxxx member in 
current execution as the calling member name found in MCALL of the MDB for the current 
Mxxx. 

Deletion : Once an MDB entry is made in the MDBT it is never deleted. 


original pm® ® 
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3.3.8 Sequential Library File Directory (LFD) 


System 


Residence : Global dynamic core; the IDX is IDXLFD in /XDBMC/ common block. 

Primary Users : UNL0AD (XUN), L0AD ( XLD ) , and DR0P (XDR) control statements. 

Description : The LFD is a table of sequential library file names that is used by the 

UNL0AD, L0AD , and DR0P control statements to insure the integrity of sequential libraries 
created or used in a particular ANOPP run. Initially allocated during system initializa- 
tion, the LFD is resident throughout an ANOPP run and is expanded whenever all allocated 
entries are in use and additional entries are required. Entries in the LLT are sorted in 
ascending binary sequence by data member name within data unit name. 


Format : 


Sequential Library File Position Common 

Directory Parameter Block 


Preface 


(See system Table Type 1 
Preface ) 


Entry ^ { lfn 


Entry { lfn 

J rnp < 


LFDEFN 


/XDBMC/ 


Entry nae 1 1 *** 


entry data: 

lfn - sequential library file name 
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Initialization ; During ANOPP initialization, XBSDBM creates the LFD using the 
following variables: 

1. The number of words of dynamic core initially allocated is determined using 
the formula: 

LEN = NTSTRT + NAELFD * LENLFE, where 
NTSTRT is a variable from /XCVT/ common block, and NAELFD and LENLFE are 
from /XDBMC/ common block. 

2. The LFD table preface is initialized as follows: 

id = IDLFD from /XDBMC/ common block 

nae = NAELFD from /XDBMC/ common block 

cne = zero 

le = LENLFE from /XDBMC/ common block 

3. The body of the LFD is set to zero. 

Entry : A new LFD entry results when a unique library file name is encountered in 

processing a L0AD or UNL0AD control statement. 

Retrieval: Entries are sequentially retrieved from the LFD by UNL0AD, L0AD, and 

DR0P to establish the existence or non-existence of a library file name and their re- 
spective control statements. 

Deletion: Entries are deleted from the LFD by the DR0P control statement. 
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3.3.9 Sequential Library Load Table (LLT) 


System Table Type : 1 

Residence : Local dynamic core; the IDX is IDXLLT in /XSLF/ common block. 

Primary Users : L0AD (XLD) control statement. 

Description : The LLT is a table of data unit and data member names which is used to 

control loading and renaming of data unit and members from a sequential library file. 

Since the LLT is local dynamic core resident, its life span is limited to each period of 
XLD execution. Expansion occurs at the rate defined by NEXPND in /XCVT/ common block when 
additional table entries are required. 


Format 


’ 

Preface 

f Entry 1 


Body 


Entry 


nee 


Entry 


Sequential Library 
Load Table 


id 

nae 

nee 

le 

entry 

data 

• 

odu 

odm 

ndu 

ndm 

• 

entry 

data 


Position Common 

Parameter Block 


(See system table type 1 
Preface) 


LLDODU 

LLDODM 

LLDNDU 

LLDNDM 


/XSLF/ 


entry data: 

odu - old data unit name 
odm - old d ca member name . 
ndu - new data unit name 
ndm - new data member name 
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Initialization : The LLT is defined at the beginning of XLD execution by subprogram 

XLDBGN using the following variables: 

1. The number of words of dynamic core initially allocated is determined using 
the formula: 

LEN = NTSTRT + NAELLT * LENLTE 

NTSTRT is defined in /XCVT/ common block, and NAELLT and LENLTE are defined 
in /XSLF/ common block. 

2. The LLT table preface is initialized as follows: 

id = IDLLT from /XSLF/ common block 
nae = NAELLT from /XSLF/ common block 
nee = zero 

le = LENLTE from /XSLF/ common block 

3. The body of the LLT is initially set to zero. 

Entry : An entry is made in the LLT for each data unit and data member named on the 
L0AD control statement, or, if none were named, for each data unit name in the Library 
Directory Record in the sequential library file (see Subsection 3.4. 5.2). If a data unit 
or member is renamed on a L0AD control statement then its new name is entered along with 
the old, otherwise the old and new names will be the same. 

Retrieval: Entries are retrieved serially from the LLT as the data units to which 

they refer are identified and loaded from a sequential library file by subprogram XLD. 

The new data unit and member names will be used to create the data member. 

Deletion: Entries are not deleted from the LLT. 


0E ifOOR ^ ■ 
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3.3.10 Sequential Library Unit Table (LUT) 


System Table Type : 1 

Residence : Local dynamic core; the IDX is IDXLUT in /XSLF/ common block. 

Primary Users : L0AD (XLD) control statement. 

Description : The LUT is a table of data unit names with their related external file 

names (EFN). It is used to validate their uniqueness against the Data Unit Directory 
(UD), (see Subsection 3.3.4) and to create UD entries for the data units being loaded. 

Allocation of the LUT is done by XLDBGN at the beginning of XLD execution and expan- 
sion will occur if the number of unique data units being loaded exceeds the number of 
allocated entries. Prior to termination, XLD frees the LUT from local dynamic core. 


Format : 


Sequential Library 
Unit Table 


Preface 


r 


Body \ 




Entry^ 


Entry 

^nce 


Entry 


nae 



entry data: 


dun - data unit name 
efn - external file name 


Position Common 

Parameter Block 


(see system table type 1 
Preface) 


LUTDUN /XSLF/ 

LUTEFN 
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Initialization : During XLD initialization, XLDBGN creates the LUT in local dynamic 

core using the following variables: 

1. The number of initially allocated words of dynamic core is determined using 
the formula: 

LEN = NTSTRT + NAELUT * LENUTE, where 

NTSTRT is defined in /XCVT/ common block, and NAELUT and LENUTE are defined 
in /XSLF/ common block. 

2. The LUT table preface is initialized as follows: 

id = IDLUT from /XSLF/ common block 

nae = NAELUT from /XSLF/ common block 

nee = zero 

le = LENUTE from /XSLF/ common block 

3. The body of the LUT is initially set to zero. 

Entry : An entry is made in the LUT for each new data unit name encountered on the 
L0AD control statement, or, if all data units are to be loaded, the names of all data 
units defined in the Library Directory Record (see Subsection 3.4. 5. 2) from the sequential 
library file. 

Retrieval : Entries are retrieved serially from the LUT and are used by XLDCDU to 

create Data Unit Directory entries (see Subsection 3.3.4) prior to the loading of data 
members . 

Deletion: Entries are not deleted from the LUT, but the LUT itself is removed from 

core when processing is complete. 






r\,V* ; 
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3.3.11 User Parameter Table (UPT) 


System Table Type : 1 

Residence : Global dynamic core; the IDX is LUPT in /XCSFM/ common block. 

Primary Users : EM modules XPA (entry), XPA, XIF (retrieval). Utilities XPUTP 

(entry), XGETP, XASKP (retrieval). 


Description : The UPT is a table of user parameters established in the control 

statement stream by the PARAM control statement or in a functional module by the Parameter 
Maintenance Function XPUTP. The parameter values are numerical, logical, or character 
string values which are maintained in the User Parameter Table or the User String Table. 


Valid UPT Table Entries: 


Type Code 


Type Value 


1 Integer 

2 Real Single 
Precision 

3 Real Double 
Precision 

6 Logical 

-n string of n 

char (A8) 


Length (words) 

1 

1 

2 

1 

(n+7)/8 


The fixed length table entry of four words is provided as the maximum length required 
for all implemented types except character strings with more than 16 characters. These 
character string values having more than 16 characters are maintained in the User String 
Table, and the UPT value entry points to the UST entry. Complex and complex double values 
have not been provided for in the UPT. 


Once a user parameter has been established in the UPT, it may be subsequently re- 
trieved or changed in the control statement stream or in a functional module. The table 
entries remain throughout ANOPP. Once established, an entry is never deleted from the set 
of known parameters. The user parameters provide a link in the communication between the 
control statement stream and a functional module* 
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Format : 


User Parameter Table 


Preface 


Body 


I 



name 


nae 


nee 


le 

r ( 


entry ? I 

entry 


data 


• 


nm 

\ entry 

type 

nee 

val /ptr 


; 

entry i 

nae 

entry 


data 

| 

1 


Position Common 

Parameter Block 


(see system table type 1 
Preface ) 


LUPTN /XCSFM/ 

LUPTT 

LUPTV 


entry data: 

nm - name of user parameter 

type - integer type code (valid types are 1, 2, 3, 6, -n) 
val - if (type .GT.O) or (type=-n and n.LE.16) then value is located in 
one or two words as required 

ptr - if type = -n and n.GT.16 pointer to position in UST of the string 
relative to start of UST . 


Initialization: During the ANOPP Initialization Phase (XBM) the UPT is created using 


the following: 

1 # The number of words of dynamic core initially allocated is determined using 
the formula: 

NWDS = LPREF + NAEUPT * LEUPT, where 
LPREF, NAEUPT, and LEUPT are in /XBSC/ common block. 

2. The UPT is initialized as follows: 

name = NAMUPT from /XBSC/ common block 

nae = NAEUPT from /XBSC/ common block 

nee = NCEUPT from /XBSC/ common block 

le = LEUPT from /XBSC/ common block 
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£ntr y= En try is made in the CS Processing Phase by PARAM CS or in the Functional 
Module Processing Phase by XPUTP. If table becomes insufficient for further entries, CDS 
block size can be expanded via DSMX by a factor of NEXPND (/XCVT/ common block). 

Retrieval: Retrieval from UPT accomplished in the CS Processing Phase by the PARAM 

and IF control statements or in the Functional Module Processing Phase by the Parameter 
Maintenance Functions XGETP and XASKP. 

Deletion : Once established in the UPT, a parameter is never deleted from the set of 

known user parameters. There is, therefore, no need for consolidation or reuse of free 
space . 
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3.3.12 User String Table (UST) 

System Table Type : 2 

Residence: Global dynamic core; the IDX is LUST in /XCSFM/ common block. 

Primary Users : EM modules XPA (entry), XPA, XIF (retrieval). Utilities XPUTP 

(entry), XGETP (retrieval). 

Description : The UST is a table of the user parameter values which are character 

strings having more than 16 characters . Entries to this table are made through the 
control statement stream by the PARAM control statement or in a functional module by the 
Parameter Maintenance Function XPUTP. A UST entry is associated with an entry in the User 

Parameter Table (UPT) which names the user parameter, gives its type code (-n) and points 

to the start of the value entry in the UST . 

The number of words required in the UST for the character string is implied by the 
integer type code in the corresponding UPT entry. Once an entry has been made in the UST, 

it subsequently may be retrieved or changed in the control statement stream or in a 

functional module. If the current character string value is being changed and the new 
value is (a) a type other than character string, (b) a character string with 16 or fewer 
characters, or (c) a character string requiring more words than the current value, then 
the current entry in the UST is "delinked" as the pointer in the UPT is changed or over- 
written with a value. There is no reuse of the "delinked" character string value or its 
space in the table. A new entry into the UST always begins at the next available word. 
Assuming that NC is the number of characters in the character string, then ABS(NC)/NCPW 
Q + R (NCPW = number of characters per word). The Q words are copied to the UST. Word Q 
+ 1 contains the R characters, left justified, blank-filled. 


OIUGWAt M®« 
0F POOR Q uaUTY ' 
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Format : 


Preface j 


Body I 




User String Table 



Position Common 

Parameter Block 


(See system table type 2 
Preface ) 


entry data; 

characters - character string (A8) 

number of words is implied by the integer type code in the 
corresponding UPT entry. 

Initialization : During the ANOPP Initialization Phase (XBM) the UPT is created using 

the following: 


1. The number of words of dynamic core initially allocated is determined using 
the formula; 

NWDS = NPREF + NAWUST, where 
LPREF and NAWUST are in /XBSC/ common block. 

2. The UST is initialized as follows: 

name = NAMUST from /XBSC/ common block 

naw = NAWUST from /XBSC/ common block 

new = NCWUST from /XBSC/ common block 

Entry : Entry is made in the CS Processing Phase by the PARAM control statement or in 

the Functional Module Processing Phase by XPUTP. If the table becomes insufficient for 
further entries, GDS block size can be expanded via DSMX by a factor of NEXPND (/XCVT/ 
common block). 
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Retrieval: Retrieval from UST is accomplished in the CS Processing Phase by the 

PARAM and IF control statements or in the Functional Module Processing Phase by the 
Parameter Maintenance Function XGETP . 

Deletion : Deletion from the UST is a result of the following situation. The current 

length of the user parameter character string is n where n is greater than 16, and the 
value is to be changed to one of the following: 

1. character string with 16 or fewer characters 

2. a type other than character string 

3. a character string with more than 16 characters which will not fit 
in the currently allocated UST entry. 

The current entry in the UST is "delinked" by the pointer in the UPT entry being 
changed or overwritten with a value. 


ORIGINAL PAGE IS 
p 00R QUALITY 


3.3-33 




EXECUTIVE MODULES 


3.4 EXECUTIVE DATA BASE STRUCTURES 

This section includes a graphical layout and a usage description of all data base 
structures used and referenced by executive modules. 

A data base structure is a table, a directory, or any other information block which 
resides on a data unit or external file. The general organizational structure of a data 
unit and a data member are also included as data base structures. 
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3.4.1 Data Unit 

A Data Unit is the highest level of the ANOPP DBM data structure that can be refer- 
enced directly using ANOPP control statements. It is physically stored on direct access 
storage devices and is uniquely identified within an ANOPP run by a data unit name. 

Since a data unit resides on a file which is identifiable outside the ANOPP system, 
its data unit name may be changed from one ANOPP run to another by relating a new data 
unit name to the same external file name. 

3. 4.1.1 Data Unit Structure 

Residence : Random Access Secondary Storage Devices 

Primary Users : Data Base Manager (DBM) 

Description : A data unit is a set of data members which is assigned via DBM to an 
external file defined by the host computer operating system. It contains a Data Unit 
Header (DUH) and Data Member Directory (DMD) which contain the information necessary to 
access and add data members . 

Format : 



Initialization : When initially created, a data unit contains only the DUH and DMD. 

3.4, 1.2 Data Unit Header (DUH) 

Residence : Data Units 

Primary Users : Data Base Manager (DBM) Subprograms 
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Description : The DUH serves as both a control structure and a data base structure. 

Although it primarily resides on data units, during ANOPP execution a copy is retained in 
the Data Unit Directory entry for each data unit. 

The DUH contains the information required to access the Data Member Directory (and 
thereby all data members) and the address of the next word that is available for output. 
Also, the DUH contains the Archive Flag which can logically inhibit outputting to a data 
unit . 


Format : 



id 

arflg 

nwa 

mda 

mdl 


data unit header identifier 
unit archive flag 
next write address 
data member directory address 
data member directory length 


Position Common 

Parameter Block 


IUHID 

IUHAF 

IUHNWA 

IUHMDA 

IUHMDL 


/XDBMC/ 


Initialization : When first generated via execution of a CREATE control statement or 

a call to XCTDU , the DUH has the following values: 

id = I DUH from /XDBMC/ common block 

arflg = 0 

nwa = LENUH+1 where LENUH is from /XDBMC/ common block 
mda = nwa 
mdl = 0 


Following creation and output, of a Data Member Directory, the mdl field will be equal 
to the DMD length and the nwa field will equal mda+mdl. 


3. 4. 1.3 Data Member Directory (DMD) 


System Table Type : 1 

Residence : Data Units 

Primary Users : DBM CREATE control statement, Data Member Manager open read (MM0PRD) , 

and close write (MMCL0S) requests. 
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Description : The DMD identifies all data members which are written to its data unit 

and contains the word address and length of each Data Member Header (DMH) . When a data 
member is opened for reading, MM0PRD searches the DMD for the name of the data member. If 
the data member is found, its DMH address and length are used to read the DMH into the 
Member Control Block* When a data member that was opened to write is closed an entry is 
made (or updated) for it in the DMD. 


Format : 


Preface 


Body I 


Data Member Directory 



Position Common 

Parameter Block 


(See system table type 1 
Preface) 


MDEDMN /XDEMC/ 

MDEMHA 

MDEMHL 


dmn - the data member name 

mha - the Data Member Header (DMH) address 

mhl - the length of the DMH 


Initialization : When initially created the DMD is zeroed and its preface is initia- 

lized as follows: 


id = IDMD from /XDBMC/ common block 
nae = NAEMD from /XDBMC/ common block 
nee = zero 

le = LENMDE from /XDBMC/ common block 

The length in words of the DMD is computed as follows : 
LEN = NTSTRT + NAEMD * LENMDE 
where NTSTRT is from /XCVT/ common block. 
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3.4.2 Data Member 

A data member is an ordered set of information which resides, in a logically con- 
tiguous fashion, on a data unit. The information can be viewed as two subsets of data, 

(1) user data and (2) non-user or Data Member Manager (DMM) data. 

User data are those data which are generated by an Executive or Functional Module and 
passed to DMM for storage and subsequent retrieval. The form and content of these data 
base structures is discussed elsewhere. 

DMM data are structures which provide information about the form, location, and 
amount of user data stored as a data member on a data unit. These structures are de- 
scribed in the following paragraphs. 

3.4. 2.1 Data Member Structure 

Residence : Data Units 

Primary Users : Data Member Manager (DMM) 

Description : A data member is composed of a Data Member Header (DMH), Record Sub- 

directories (RS), and data records which are addressed using the RS. 

Format : 


MGE m 
O F PC^K QUALET5J 


DMH 


RS 


us er 
data 
records 
1 thru n 


RS 


user 
data 
records 
n+1 thru last 
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DMH - the data member header is variable length and contains the Master Record 
Directory (RD) which indexes the RS. 

RS - the record subdirectories are variable length with their number and 

length dependent on the maximum number of records specified by the user 
when the member was created. 

Life Span : The life span of a data member on an external storage device is dependent 

upon the user T s retention of the data unit to which it is assigned. 

Initialization : Not applicable 

3.4. 2. 2 Data Member Header (DMH) 

Residence : Data Members 

Primary Users : Data Member Manager (DMM) 

Description : The DMH is the source of quantitative, historic, and reference informa- 

tion for a data member. It consists of a Preface, Format Specification Image, Format 
Specification Table, and Record Directory. When a data member is opened for writing, the 
DMH is created as part of the Member Control Block (MCB) , Section 3.3.6, and space is 
reserved for it at the beginning of the data member. As the data member is written, 
information on number of records written, maximum record length, and number of Record 
Subdirectories written is stored in the DMH. Closing the data member causes the DMH to be 
written on the data unit preceeding the other data member data. Subsequent opening of the 
data member for reading will cause the DMH to be read into the MCB. 
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Format : 


Data Member Header 


Body 


DMH 

Preface 


dmn 

len 

mnr 

cnr 

mrl 

f fhl 

vtl 

date 

time 

rdl 

I"" nrs 

fsil 

fstl 

FSI 

FST 

RD 


Position 

Parameter 

MHDMN 

MHLEN 

MHMNR 

MHCNR 

MHMRL 

MHFHL 

MHVTL 

MHDATE 

MHTIME 

MHRDL 

MHNRS 

MHFSIL 

MHFSTL 

MHFSI 


Common 

Block 

/XDBMC/ 


dmn 

len 

mnr 

cnr 

mrl 

fhl 

vtl 

date 

time 

rdl 

nrs 

fsil 

fstl 

FSI 

FST 

RD 


data member name 
member header length 

maximum number of data records specified in the open member reque . 

current number of user records 

maximum record length 

fixed header length 

length of repeated variable trailer 

date member created in form YY/MM/DD 

time member created HH.MM.SS 

record directory record length 

number of record subdirectories 

format specification image length 

format specification table length 

format specification image 

format specification table 

record directory 


Initialization : 


When the DMH is first created, the following fields are initialized: 


dmn 

len 

mnr 

cnr 

mrl 

fhl 


vtl 


NAMA( 2) from /XDBMC/ common block 

MHSFSI + FSIL + FSTL + RDL, where MHSFSI is from /XDBMC/ common block 

and FSIL, FSTL, and RDL are entries in the data member header 

10000 if mnr specified open member request is zero; otherwise, unchanged 

0 

LENFH where LENFH is computed by MMBFST and is summation of ^element 
lengths of the fixed part of format specification if FSI is non-zero, 

LENRg'* where LENRG is the summation of the lengths of the elements 
in the variable part of the record if the FST specifies a van 
length formatted record; otherwise zero 
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by I DATE 

by ITIME x 

LENRDB = (MNR)^ + 2.99999 

0 

LENFSI length of format specification image as determined by MMBFSI 

LENFST length of format specification image as determined by MMBFST 

The initialization of FSI, FST , and RD are discussed in their subsections. 

3. 4. 2. 3 Format Specification Image (FSI) 

Residence : Data Member Headers 

Primary Users : Data Member Manager (DMM) open write routines, L0AD, UNL0AD , and 

UPDATE control statements. 

Description: The ESI cannot be described with the tabular presentation used for 

other data base structures. It is a Hollerith string of ANOPP data type descriptors which 
are separated by commas. The data types may be grouped using parentheses. Single data 
types and groups may be prefixed by an integer character string or an asterisk to indicate 
repetition. The FSI is always terminated with a dollar sign. If the data member which 
the FSI describes is unformatted then the FSI will be one word of binary zeroes. The FSI 

is initially created by subprogram MMBFSI from the format specification provided on DMM 

open write requests (MM0PWD, MM0PWS ) and is stored in the Data Member Header. The L0AD, 
UNL0AD, and UPDATE control statements retrieve it from there for their own use. 

Format : Not applicable 

L i- fe s P an: The FSI is core resident in a MCB when a data member is open. The in- 

core life span of a particular FSI is, therefore, dependent upon how long the data member 
remains open to a module. 

The life span of the FSI on secondary storage devices is dependent upon the retention 
period of the file on which its data member and unit reside. 

Initialization : Not applicable 


date = 
time = 
rdl - 
nrs = 
fsil = 
fstl = 
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3.4. 2.4 Format Specification Table (FST) 


Residence : Data Member Headers 

Primary Users : Data Member Manager (DMM) get and put element routines (MMGETE, 

MMPUTE) 

Description : The FST is an array of element descriptors which specify the format of 

records contained on, or to be written to, a particular data member. The element de- 
scriptors have the following formats: 

Single Element Descriptor 

A single element descriptor is one word in length and its value is less than 
seven and not equal to zero. The length of the element is determined as follows: 

1. If the element type (value) is greater than zero then the value is 

used as an index to the NDTCL table in /XCVT/ common (ELEN = NDTCL( VALUE ,3) ) . 

2. If the element descriptor value is negative then the value is the absolute 
value of the element descriptor value and the length is based on the 

NCPW variable in /XCVT/ (ELEN = ( -VALUE+NCPW-1 ) /NCPW ) . 


Repeated Group Descriptor 

A repeated group descriptor is built when the users format requires one or more 
elements or element groups to be repeated in the record. Nesting of repeated groups 
is permitted. The repeated group descriptor consists of a three word header, a group 
of element descriptors of any type, and a two word trailer* 

Several subprograms were written to manage the FST for DMM. They are: 

1. MMGED - get next element description 

2. MMGNEW - determine the number of elements that fit an array of NWDS words 

3. MMGNWE - determine the number of words required to write the next NEL elements 

4. MMSFEI - reset the FST element index based on the number of words read or 

written in the current record 
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Format: The following format represents a user format of the type I, 

RS, 3(A3,RS),*RD $. 


Table Format Specification Position Common 

^ndex Table Parameter Block 


f 


Format 

of 

Fixed 

Length 

Header 


I Fixed 
J length 
\ repeat 
] group 




r 


Format 

of J 

Variable \ 
Length I 
Trailer | 


variable 

length 

repeat 

group 


V 


1 

e i 

1 

2 

C 2 

2 

r 3 

rgh 1 

22 

4 

rpt j 

3 

5 

cnt^ 

0 

( 6 

re i 

-3 

7 

re 2 

2 

8 

rg-q 

23 

, 9 

rtn^ 

3 

( 10 

rgh 2 

22 

11 

rpt 2 

0 

12 

cnt 2 

0 

13 

re 3 

3 

14 

rgt 2 

23 ) 

, 15 

rtn 2 

10 1 


repeat 

group IRGRPT 
header IRGCNT 

repeat 

group IRGRTN 
trailer 

repeat 

group 

header 

repeat 

group 

trailer 


/XDBMC/ 


e l ,e 2’ re l’ re 2’ and re 3 
rgh a and rgh 2 

rpt^and rpt^ 

cnt^ and cnt 2 
rgt 1 and rgt 2 

rtn^ and rtn 2 


- all Single Element Descriptors having a value greater 
than -133, less than 7, and not zero 

- repeat group element types with a value equal to IRGME 
in /XDBMC/ common block. They indicate the beginning 
of a repeat group header 

- contain the integer number of times the elements bracketed 
by the repeat group headers and trailer are to be repeated, 
rpt^ , is greater than zero indicating the repeat group has 

a fixed number of repetitions, while rpt 2 is zero indicat- 
ing an indefinite number 

- are zero and are used in element level processing to 
control the number of times a repeat group is repeated 

- repeat group trailer element types with a value equal to 
IRGTE in /XDBMC/ common block. They indicate the beginning 
of repeat group trailer 

- indices, relative to the beginning of the FST, to their 
related repeat group header 


Initialization : Not applicable 


i 
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3. 4. 2. 5 Record Directories (RD) 

Residence : Data Members 

Primary Users : Data Member Manager (DMM) get and put subprograms 

Description : The Record Directory is the first level of a two level data record' 

index which provide DMM with a unified approach to random and sequential accessing of 
fixed format, variable format, and unformatted records. The RD is the index to the 
second level, the Record Subdirectory (RS), which contains the secondary storage addresses 
(relative to beginning of data member) (word addresses on CDC CYBER computer system) of 
the actual data records. 

The RD record has a fixed format and, within a data member, a fixed length. However, 
from data member to data member the length may differ depending on the maximum number of 
records (MNR) the user has allocated to a member at open time (MM0PWD, MM0PWS). This 
length is calculated using the following algorithm: 

LEN = (MNR)* 5 + 2.9999 

where LEN is integer and the result is truncated. 

Format : 


Record Directory 



id - RD identifier 

wa - the addresses of the secondary storage addresses of RS. 
i 

Initialization: The R record is zeroed prior to use. 
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3*4, 2,6 Record Subdirectory (RS) 


Residence : Data Member 

Primary Users : Data Member Manager (DMM) get and put subprograms 

Description . The RS is the second leveX of a two level data record index which 
contains the secondary storage addresses relative to the beginning of the data member 
(word addresses on CDC CYBER computer system) of the actual data record. 

The RS record has a fixed format and, within a data member, a fixed length. 
Format : 



id - table identifier 

wa i - addresses of the secondary storage addresses of data records 
nxtwa - chain word from current to the next RS record 

Initialization : The RS record is zeroed prior to use. 

id = IDRS from /XDBMC/ common block. 
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3.4.3 Data Table Types 

Residence: Data Tables reside on the unit specified by the user when the table is 

built. While the table is open for processing, it resides in Global Dynamic Storage. 

Primary Users : EM modules XTB and DBM module TMBLD1 which build Data Tables and DBM 
module TMTERP which retrieves an interpolated dependent variable from a currently open 
table. 

Description : A data table is a user created table of data available to the function- 

al modules for processing. It is a one-record member having an internal format corre- 
sponding to one of the Data Table Structures defined. Currently, only Type 1 data tables 
have been implemented. 

The general table structure consists of a fixed length preface of identical format 
for all tables and a variable length body of specific format for the individual table 
type. A Data Table is built through the control statement stream using the TABLE control 
statement or in a functional module using the DBM table build routines. 

When first opened for processing (TM0PN), a table is read into core and its name is 
entered into the table directory. When closed (TMCL0S) the table remains in core and is 
logically closed in the directory. Subsequent opens will take place in core via the 
directory. If a table is altered while it is open in core, it should be closed with a 
close alter (TMCLSA) so that a copy will be placed on the original member it came from. 
This is necessary to preserve the integrity of the table under the following conditions: 
(a) while a table is logically closed in the table directory it can be removed from the 
directory for one of two reasons: (1) to make room for other tables or (2) because member 
manager is processing the member for writing; and (b) when the table is removed from the 
directory, a subsequent open will read a new copy of the member into core and place its 
name into the table direectory. 
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Format : 


Preface 


Body 



Position Common 

Parameter Block 

NDTID /XDTMC/ 

NDTTP 

NDTLN 


NDTST 


idtabl - data table identifier (8HDATATABL) 
type - table type (integer number) 

length - length of this table (includes Preface and Body) 
rsvd - reserved four words 


Initialization: There is no initialization. 


Life Span : A data table remains in core until: (1) it is closed and its space in the 
table directory is needed to open another table, (2) it is being processed by member 
manager for writing, or (3) the termination of the current ANOPP run, whichever comes 
first. 


3.4. 3.1 Data Table Type 1 


Description : For a full description of Data Tables Residence, Primary Users, Life 

Span, Initialization, see Section 3.4.3. A Type 1 table defines a Data Table body format 
which specifies interpolation procedures acceptable on this table and the interpolation 
procedures to be used when an interpolation request is outside the table range of the 
independent variable. 

> 
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Format : 


Preface 


Body 


Data Table Type 1 






nind 


idscrp 


nint 


int 


itypdv 


a i 


a 2 


a 3 


adv 


(See data table 
type preface) 


nind 

idscrp 


nint 

int 


number of independent variables in this table . LE.3 
array of dimension nind *4 

idscrp(4*i-3) - format code of ith independent variable 

0 - ordered position from 1 to number of 

elements in independent variable array* 

In this case a. does not exist. 

1 - integer (I) 

2 - real single (RS) 

3 - real double (RD) 

idscrp(4*i-2) - integer number of ith independent variables 
idscrp(4*i-l) - exrapolation procedure to be used if the ith 

independent variable value supplied is greater 
than largest value of the ith independent 
variable in the table 

0 - extrapolation not allowed 

1 - use closest independent variable value 

2 - extrapolate 

idscrp(4*i) - exrapolation procedures to be used if the value 
supplied is less than the smallest value of the 
ith independent variable 

0 - extrapolation not allowed 

1 - use closest independent variable value 

2 - extrapolate 

number of elements in array containing interpolation procedures 
acceptable on this table 

array containing one or more integer codes of interpolation 
procedures acceptable on this table . Acceptable codes are : 

0 - no interpolation 

1 - linear interpolation 
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itypdv 


a l’ a 2’ a 3 


adv 


format code of dependent variable 

1 - integer (I) 

2 - real single (RS) 

3 - real double (RD) 

one-dimensional arrays of values for the first, second, and third 
independent variables , if they exist . Values must be arranged 
in monotonically increasing or decreasing order 
nind-dimensional array of dependent variable values such that 
the first independent variable varies first, the second variable 
second, and the third, third. 
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Format * 



LDR - see Subsection 3. 4. 4. 2 

LUH - see Subsection 3. 4. 4. 3 

LDM - see Subsection 3. 4. 4. 4 

EOS - CYBER Record Manager End-of-section 

EOP - CYBER Record Manager End-of-partition 

EOF - CYBER Record Manager End-of-file 


Life Span : During an ANOPP run an SLF is available for use following its creation by 

UNL0AD or, if it was existent before the run, at any time via L0AD. A SLF may be made 
unavailable within ANOPP through use of the DR0P control statement. This, however, will 
also remove the file from the ANOPP run T s operating environment and it cannot be reestab- 
lished within ANOPP. 

Initialization : See Subsections 3.4. 4. 2 through 3. 4. 4. 4. 


^OOB L aj AGE IS 

°OR quality 
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3.4.4 Sequential Library 

3. 4.4.1 Sequential Library File Structure (SLF) 

Residence : ANOPP library files reside on secondary storage devices (rotating mass 

storage or magnetic tape) and are identified by a file name known to both ANOPP DBM and 
the host computer operating system. 

Primary Users : L0AD (XLD) and UNL0AD (XUN) control statements. 

Description : A Sequential Library File is a set of data units, and a complete or 

partial subset of their data members, which has been converted from random to sequential 
access file structure. Data units and members within units are unloaded to the SLF, by 
name, in ascending binary sequence to permit optimization of data unit and member loading. 
Once created, individual data units or members on a SLF cannot be modified in place with- 
out destroying the entire set of units. 

On CDC CYBER computer systems the SLF will be recorded using Cyber Record Manager 
internal blocking (BT=I) and data records will be preceded by a control word (RT=W). This 
will provide: (1) efficient data transfer to all types of secondary storage devices, (2) 
maximum data recoverability if errors are encountered when loading from the SLF, and (3) 
compatibility between CYBER 76 and other CYBER Series computers. 
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3.4.4. 2 Library Directory Record (LDR) 

System Table Type : 1 

Residence : Sequential Library Files (SLF ) and Local Dynamic core storage; the IDX is 

IDXLDR in /XSLF/ common block. 

Primary Users : UNL0AD (XUN) and L0AD (XLD) control statements 

Description : The LDR is a type 1 system table created by XUN which contains a sorted 

list of the names of all data members (with their respective data unit names) that were 
unloaded to the SLF. The LDR is written as the first record on a SLF by XUN and is sub- 
sequently used to control the sequence in which data units and members are unloaded. XLD 
uses the LDR to insure the existence of data members named on a L0AD control statement 
prior to processing. 

Format : 

Position Common 

Library Directory Record Parameter Block 


(See system table type 1 
Preface) 


LDRDUN /XSLF/ 


dun - data unit name 
dmn - data member name 


Preface 


Body 



id 


nae 


nee 


le 

Entry \ 

entry 

1 1 

data 


* 

Entry. 1 

dun 

1 1 

dmn 


• 

Entr ^nae j 

entry 

data 
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Life Span : Since the LDR is recorded on a sequential library file, its life span 

outside ANOPP is dependent upon retention of the SLF by the user. Within ANOPP a par- 
ticular LDR is resident during XUN and XLD processing and is available from sequential 
libraries. 

Initialization : XUNBGN allocates the LDR at the beginning of UNL0AD control state- 

ment processing as follows: 

1. The number of words initially allocated to the LDR is determined by: 

LEN = NTSTRT + NAELDR * LENDRE, where 
NTSTRT is a variable from /XCVT/ common block, and NAELDR and LENDRE are from 
/XSLF/ common block. 

2. The LDR preface is initialized with the following: 

id = IDLDR from /XSLF/ common block 
nae = NAELDR from /XSLF/ common block 
nee = set to zero 

le = LENDRE from /XSLF/ common block 

3. The body of the LDR is initially set to zero. 

3.4.4. 3 Library Data Unit Header (LUH) 

Residence : Sequential Library Files (SLF) 

Primary Users : L0AD (XLD) and UNL0AD (XUN) control statements 

Description : The LUH is a subset of information from the Data Unit Header that is 

necessary to identify and restore the original data unit when it is loaded. It is gene- 
rated by UNL0AD and indicates the start of a new data unit on sequential library files. 
The LUH has a fixed record length specified by LEN LUH in the /XSLF/ common block. 
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Format : 

Position Common 

Library Data Unit Header Parameter Block 

LUHID /XSLF / 

LUH DUN 
LUHAF 
LUHNDM 


LUH Record identifier (Hollerith) 

Data Unit Name 
Archived Data Unit Flag 

Number of data members unloaded from the named data unit 


id 

dun 

arflg - 
ndm 


id 

dun 

arflg 

ndm 


Life Span : The life span of the LUH depends on the retention period for the se- 

quential library file on which it resides. 

Initialization : 

id = IDLUH from the /XSLF/ common block 

dun = initialized with the Data Unit Name variable from the related DUD entry 

arflg = initialized with the Archive Flag variable from the related DUD entry . 

ndm = initialized with the number of members to be unloaded from the specified 

data unit 


3. 4. 4. 4 Library Data Member Structure (LDM) 

Residence : ANOPP Library Files 

Primary Users : L0AD and UNL0AD control statements 

Description : The LDM is a copy of a data member on an ANOPP data unit* It contains 
all of the information contained on the data member including the Data Member Header, 
Record Directory and Subdirectories. 
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Format: 


Library Data Member Structure 



DMH - the Data Member Header is variable length and contains the Record 
Directory (RD) which indexes the RS. 

RS - Record Subdirectories are variable length with their number and 

length dependent on the maximum number of records specified by the 
user when the member was created. 

Life Span : The life span of a particular LDM is dependent upon the retention period 

for the file on which it resides. 

Initialization : Not applicable 
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3.4.5 Executive Management System Reserved Units 

The Executive Scratch unit and Data unit are created by XBSDBM which initializes the 
Data Base Management System. They exist throughout ANOPP execution. 

3.4. 5.1 Executive Management System Scratch Unit 

Residence : The Executive scratch unit resides on a random access secondary storage 

device and is identified by the name NXUNIT from /XCS/ common block. 

Primary Users : The Executive Scratch Unit is used by XRT (The Primary Edit Phase), 

XCA (The Secondary Edit Phase), XCSP (The Control Statement Processing Phase), and UPDATE. 

Description : The Executive Scratch Unit is a set of Mxxx and Uxxx data members 

(described in the following sections). It contains a Data Unit 'Header (DUH) and a Data 
Member Directory (DMD) which contain the information necessary to access and add members. 
The format of a data unit in general are described in Section 3.4.1. 1. 

3.4. 5.1.1 Mxxx Member 

Residence : The Mxxx Member resides on the Executive Management System (EM) scratch 

unit XSUNIT. 

Primary Users : EM modules XRT and XCA which construct Mxxx Members and EM modules 

XCSP and XMERR which use Mxxx members for processing. 

Description : xxx is a display code of integers 001 through 999. M001, the root 

member, is built from the control statement images in the Primary Input Stream. M001 is 
created during the Primary Edit Phase by XRT and contains the Primary Control Statement 
Set in executable form. 

Mxxx, xxx. GT. 001, is created during the Secondary Edit Phase in XCSP when a CALL CS 
is encountered and contains a Secondary Control Statement Set in executable form. The 
number xxx is assigned sequentially from 002 as each CALL CS is encountered for the first 
time. 
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An Mxxx Member is made up of N unformatted, variable length records. The first N-l 
records are f&xx Control Statement Records (CS Records), one CS Record for each CS image 
encountered in the input stream, and the last record is the Mxxx Label Record. 

A CS Record is the executable form of one complete CS image supplied by the user in 
the Primary or Secondary Input Stream. The CS records are sequenced in the order corre- 
sponding to the occurrence of the CS in the Primary Input Stream. 

The Label Record contains an entry for each labelled control statement in the CS 
stream and specifies all label names and their corresponding CS record location. The 
Label Record is variable length depending on the number of label entries. However, the 
presence of the Preface always insures a Label Record length of .GE.l. 

Format : 

Mxxx Member 

Record^ 


Record.. 4 
N-l 

Record,, 

N 

where N is the number of records on Mxxx 
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Format : 


Preface 


Body 


Control Statement Record 


Position 

Parameter 




0DB 1 


0DB . 
1 


» DB „„db 


len 

lab 

nam 

nimg 

nodb 

stodb 

mem 

stimg 

• 

endimg 

entry 

data 


( type 

| value 

• 

| entry 

i data 


KLCS 

KCSLAB 

KCSN 

KNIMG 

KN0DB 

K0DB 

KMEM 

KIMG 



Common 

Block 

/xcs/ 
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Preface 


len 

lab 

nam 

nimg 

nodb 

stodb 

mem 


stimg 

ending 

Body 


ODB . 

l 


Format : 


' ESSVE ? th ? cs ^ 

for the CS iwg.. The »ax™ p ^ 
cards allowed per CS)* (mimhe-n ® s 7+ (maximum 

is (7 + 5 * 10) or 57. WOrds P6r Card irna S e) which 

- number of words in this record 

- ™ U8> “ tU * CS h * d 8 label - °f herwise blank 

- number of words in the CS image 

- s^t r oftSe e SSB d en?ri riPtl r B1 ° CkS (f5DB) in *»• "S record 

l? nt if n this e is^a t CALL°^l°^ n ^ t *”*f^ std ^ P *” d ^ Pg0 ° nt ^ eC ^ sR *^®^* 

sr — --- srs 22+sa 

if this is an UPDATE CS or TABLE CS ui+h = «. 
of the Uxxx Member <A8) which conSinf^ T- = " 7 ™ 
.if not 1 or 2. then blanS thg lmage in P ut 

CS image in A8 format. Length of the CS TMAcr / v 

■ ZTc?L g ( ' M ~ ° f *— »- -3 2S> l “ b - of — 

’ Each b neld S or a delSi?L°(^er ^f ription Block (0M > entries. 

CS name on the CS card image(s) has an"oDB°ent lan ^ f ° llowin S the 
encountered on the CS card Image 7 ln the ° rder 

Operand Description Block entrv - variahi* 

field encountered in the CS The M p 1 ' engt h. entry for each 

t°he t f h i e el f d eld an<3 the f ° ll0wing W ° rd(s) c^taln^rihe^l^f 

Type - ANOPP integer type code of field 
alue - field value - length implied by type code 


2 . 


3 . 


nent 

name 

ncs 


Preface j 

r 


Body 





Position 

Parameter 

KNLAB 

KLAB 


KLNAME 

KNCS 


Common 

Block 

/xcs/ 


- word preface contains the number of entries 

- label name (A8) 


in 


- number record within the Mxxx member 
within the Mxxx member. 


of the CS 


this record 
with this label 
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Life Span : The Mxxx Members, built during the Primary or Secondary Edit Phase of 

ANOPP, exist during ANOPP execution. 

Initialization : There is no initialization. Once the Mxxx Member is created, it is 

not altered. 

3.4. 5.1.2 Uxxx Member 

Residence : The Uxxx Member resides on the Executive Management Scratch Unit XSUNIT. 

Primary Users : EM module XRT which constructs the Uxxx Member and EM module XCSP 

which uses the Uxxx member for processing. The TABLE and UPDATE control statements. 

Description : The Uxxx Member is created during the Primary Edit Phase by XRT when- 

ever an UPDATE or TABLE control statement with a source = * field is encountered in the 
Primary Input Stream and contains the UPDATE or TABLE input which immediately follows the 
corresponding control statement in the Primary Input Stream. This input, in card image 
format (10AB), is to be used as source input during execution of the corresponding UPDATE 
or TABLE control statements. 

xxx is a display code of integers 001 through 999. The number xxx is assigned 
sequentially from 001 as each TABLE or UPDATE control statement is encountered during the 
Primary Edit Phase. 

Format : 

Record^ 

Records 

where N is the number of input card images on the Uxxx Member. 

Initialization : There is no initialization. Once the Uxxx Member is created, it is 

not altered. 


Uxxx Member 
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3.4. 5.2 Data Unit 

Residence : The DATA unit resides on a random access secondary storage device and is 

identified by the name NDATA from /XCS/ common block. 

Primary Users : XRT (the Primary Edit Phase) builds the members on DATA and DBM 

modules access members built on DATA. 

Description ; DATA contains Data Unit Header (DUH) and a Data Member Directory (DMD) 
which contain information necessary to access and add data members. The DUH and DMD are 
followed by the data members which are built during the Primary Edit Phase (XRT) whenever 
a DATA control statement is encountered. The members are built in card image format from 
the card images which follow the DATA control statement in the input stream until an END* 
control statement is encountered. The format of data unit in general is described in 
Section 3. 4. 1.1. 

Format: 



DUH - data unit header 

DMD - data member directory 

members - card image format 

Life Span : DATA unit exists throughout ANOPP execution. 

Initialization : When initially created by XBSDBM, DATA contains only the DIM and 

DMD. Their initial settings established by XCTDU are described in Sections 3. 4. 1.2 and 
3.4.1. 3, respectively. 
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3.5 EXECUTIVE MANAGEMENT SYSTEM 
3.5.1 Overview 

The Executive Management System (EM) controls the execution of ANOPP from beginning 
to end. The following tasks are required to accomplish this control: 

1. Perform initialization requirements for the Executive Management System 
(EM), the Data Base Management System (DBM), the Dynamic Storage Management 
System (DSM ) , and the General Utilities. 

2. Validate the required user supplied set of control statements which defines 
the execution sequence. 

3. ' Direct the order of execution dynamically via the required set and the optional 

set(s) of control statements supplied by the user. 

4. Control the execution of Functional Modules (F.M.) by transferring execution 
control to the specified F.M. and by insuring the integrity of the ANOPP system 

environment upon completion of the F.M. 

5. Direct the action to be taken upon encountering a non-fatal error during 

execution of ANOPP. 

6. Validate the optional set(s) of control , statements which define secondary 
execution sequence(s) to be performed. 

7. Terminate ANOPP when all required tasks have been accomplished. 

8. Abort ANOPP if a fatal error occurs during the performance of the above tasks. 

ANOPP is controlled by a set of control statements called the Primary Input Stream. 
The Primary Input Stream consists of an optional initialization control statement and a 
required execution section which defines the execution sequence. The ANOPP control 
statement allows the user to define selected ANOPP initialization parameters. The exe- 
cution section begins with a STARTCS control statement followed by the control statements 
defining the execution sequence and ends with an ENDCS control statement. 

Additional control statement sets may define secondary execution sequences to be 
dynamically executed via a CALL control statement. The additional control statement 


3.5-1 



EXECUTIVE MODULES 


set is called a Secondary Input Stream and resides as a data member in card image format. 
The Secondary Input Stream may be prepared prior to the current ANOPP execution or it may 

be created within the execution sequence prior to the corresponding CALL control state- 
ment. 

Executive Monitor (XM) is the driver module for the Executive Management System. XM 
is also the main FORTRAN program for ANOPP and remains in core at all times. 

The Executive Management System is composed of eight execution phases which are 
controlled directly or indirectly by the XM driver module. The following execution phases 
correspond to the eight Executive Management System tasks previously stated: 

1. Initialization Phase 

2. Primary Edit Phase 

3. Control Statement Processing Phase 

4. Functional Module Processing Phase 

5. Error Processing Phase 

6. Secondary Edit Phase 

7. Normal Termination Phase 

8. Error Termination Phase 

3*5.2 Control Statements 

A control statement is one or more cards or card images which defines a particular 
action to be performed by the ANOPP Executive Management System. A set of control state- 
ments is one or more statements which are ordered sequentially to define an execution 
sequence. et is executed sequentially from the first control statement through the 
last control statement in the set. The sequential flow may be altered, however, by 
special control statements which transfer execution control to a specified control state- 
ment in the same set or the beginning of another set. There are two types of control 
statement sets, the Primary Input Stream and the Secondary Input Stream. 
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3.5. 2.1 Primary Input Stream 

The Primary Input Stream is a required set of input cards. It consists of an op- 
tional initialization control statement (CS), the AN0PP CS, and a required execution 
section. The AN0PP CS allows the user to define initialization values for selected 
executive module parameters. If present, it must be the first CS in the Primary Input 
Stream. If omitted, all parameters are initialized according to predefined installation 
values. The execution section begins with a STARTCS control statement followed by control 
statements defining the execution sequence and ends with an ENDCS control statement. If 
the ANOPP CS is not present, STARTCS is the first card in the Primary Input Stream. 

3. 5.2.2 Secondary Input Stream 

A Secondary Input Stream is an optional set of card images which resides as a data 
member in card image (Cl) format. A CALL in the Primary Input Stream brings into exe- 
cution a Secondary Input Stream which may also contain a CALL. There is no limit to the 
number of nested CALL control statements. There is no required first or last control 
statement (CS) in a Secondary Input Stream. The execution sequence begins with the first 
CS and ends with the last CS. However all control statements or control statement forms 
defined for ANOPP are not available for usage in a Secondary Input Stream. The invalid 
control statements are generally those which require card input to immediately follow the 
CS. An example is the DATA control statement (see Section 3. 5. 2. 4. 7). All control state- 
ments of this type require the END* card (see Section 3.5.2.4.11) to terminate the input 
and are valid in the Primary Input Stream only. The ANOPP, STARTCS and ENDCS control 
statements are also invalid in the Secondary Input Stream. The validity of each CS with 
respect to usage is given in the specific CS description section (see Section 3. 5.2.4). 
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3. 5.2. 3 General Description 


3. 5. 2. 3.1 Format 


The general format of a control statement (CS) is shown below: 

label^csname^op $ comments 


where : 

label 

i 

csname 

op 

$ 


an optional 1-8 character alphanumberic name tag which will be 
associated with this directive. A label is allowed on any control 
statement except AN0PP, STARTCS, END*, and RETURN. 

a comma or a blank 

a valid 1-6 character alphanumeric control statement name 

operand field(s) as appropriate to particular control statement 

the end-of-data character which indicates completion of a CS. 

The remainder of the card may be comment. 


3. 5. 2. 3. 2 Valid Control Statement Names 


Valid control statement names recognized by the ANOPP system are shown below: 


AN0PP 

DATA 

G0T0 

RETURN 

ARCHIVE 

DETACH 

IF 

SETSYS 

ATTACH 

DR0P 

L0AD 

STARTCS 

CALL 

ENDCS 

PARAM 

TABLE 

C0NTINUE 

END* 

PR0CEED 

UNL0AD 

CREATE 

EXECUTE 

PURGE 

UPDATE 


3. 5. 2. 3. 3 Free-Field Form 

A CS directive is free-field form on a card image in columns 1-80. The fields 
(including label and CS name) may begin in any column. Blanks or commas may be used 
freely between fields for spacing and are ignored. 


3 . 5 . 2 . 3 . 4 Comments 


A comment may follow the end-of-data character ($) on a card image and extend through 
column 80. A comment card is a card image (other than a CS continuation card) with the 
first non-blank character, other than a comma, being a $. The remainder of the card is 
processed as a comment. 
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3. 5.2.3. 5 Continuation 

A CS may require more than one card image for completion. A maximum of 5 continua- 
tion cards are allowed with the end-of-dat a ($) character appearing on the last card image 
required. A Hollerith field type may be continued to column 1 of the continuation card 
image; however, the nH portion which identifies it as Hollerith must not be split between 
two card images. No other field types may be split between two card images. Comments may 
not be continued (except as multiple comment cards). 

3. 5.2.4 Specific Descriptions 

On the following control statements (CS) an optional field is enclosed in [ ] . The 
symbol i represents a blank. The alphabetic letter is slashed when appearing on a card 
image (e.g., alpha 0, numeric 0, alpha 2, numeric 2). 

3. 5. 2. 4.1 AN0PP 

Purpose : The AN0PP control statement is optional and provides for user-specified 

values to be used for executive system parameters during the ANOPP run instead of system 
defined default values. If used, it must be the first control statement in the Primary 
Input Stream immediately preceding the STARTCS control statement. 

Format ; 

AN0PP^keyword^=value^[^. . .^keyword^value^] $ 

keyword - the name of the parameter whose default value the user wishes to override 
or replace. A list of valid keywords with their corresponding acceptable 
replacement values and system default values is given in the ANOPP Keyword 
Table (see Table 1). 

value - the value which is to replace the system default value for the corre- 
sponding keyword. A label field is not allowed on the AN0PP statement. 

Examples : 

AN0PP JECH0= . TRUE . $ 

AN0PP , JL0G= . TRUE . JECH0 =.TRUE. $ 

AN0PP NLPPM = 40, LENGL= 30000, JL0G = .FALSE. $ 

Restriction: ANOPP is valid only as the first CS in the Primary Input Stream. 
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KEYWORD 

JECH0 


JL0G 

LENGL 

NAETD 

NAEUD 

NLPPM 

N0G0 


RANGE OF 

DESCRIPTION ACCEPTABLE VALUES DEFAULT PARAMETERS 

Residence Name Value 


Print card images from 
the primary input stream 
or from a member (via a 
CA11 CS) as they are 
validated in Primary Edit 
Phase and Secondardy 
Edit Phase 

JECH0 = .TRUE, then print 
card images 

JECH0 = .FALSE, then do 
not print card 
images 

Print card images of 
control statements as 
executed in the Control 
Statement Processing 
Phase 

JL0G = .TRUE, then print 
card images 

JL0G = .FALSE, then do 
not print card 
images 

Length of global dynamic 
storage initialized for 
this ANOPP run 

Number of initially 
allocated entries in the 
Table Directory 

Number of initially 
allocated entries in the 
United Directory 

Number of lines per 
printed pages to be 
used for all ANOPP 
printed output 

PRIMARY EDIT ONLY 
N0G0 = * TRUE . then 

terminate ANOPP after 
Primary Edit Phase 
N0G0= .FALSE, then do 
not terminate ANOPP after 
Primary Edit Phase 


•TRUE. /XSPT/ JECH0 .FALSE. 

.FALSE. 


•TRUE. /XSPT/ JL0G .TRUE. 

.FALSE. 

Integer „ 3000 

* 10- 10 /XCVT/ LENGL 20,000 o 

8 

Integer > 1 /XDTMC/ NAETD 10 

Integer > 4 /XDBMC/ NAEUD 25 10 

Integer 15 1Q < NLPPM /XCSFM/ NLPPM 48 1Q 

•TRUE. /XCS/ N0G0 .FALSE. 


.FALSE. 


Table 1. ANOPP Control Statement Keyword Table. 
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3. 5. 2. 4. 2 ARCHIVE 

Purpose : The ARCHIVE control statement permanently prohibits any request to write on 

the named unit or units. 

Format : 

[label^] ARCHIVE jl du 1 [ . . . ^du R ] $ 
label - label name 

du - name of the data unit to be archived 

The specified unit(s) are permanently archived 
are permitted. The archive indicator is written to 
the unit(s) even in subsequent ANOPP runs. 

Examples : 

LAB, ARCHIVE Ul, U2 U10 , U50 $ 

ARCHIVE, U50 $ 

3. 5.2.4. 3 ATTACH 

Purpose : The ATTACH control statement attaches data units to the internal system 

which were previously created on direct access files and are presently assigned in the 
external system. 

Format : 

[label J ATTACH^du^/efny] [.. ,du n [/efn n /]l $ 
label - label name 

du - name of data unit to be attached 

efn - name of the external file associated with du 

An entry is made in the Unit Directory for each data unit named (du) and the external 
file name specified (efn) is associated with the unit. 


and no future writes to the unit(s) 
the unit thus prohibiting output to 
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Examples : 


ATTACH UNIT1/M0150/ , UNIT2/U001/ $ 
ATTACH UNIT2/EFN/ $ 


Restriction : Data units appearing on the ATTACH CS must have appeared on a DETACH CS 

in this or a previous ANOPP execution. 


3. 5. 2.4.4 CALL 


Purpose : The CALL control statement executes a set of control statements which have 
been previously created in card image format (Cl) on a data member of a data unit. Prior 
to execution the CS images will be altered according to specified value replacements. 

Format : 

[label^]CALL^du(dm) [,oldvalue^=newvalue^ , . . . .oldvalue^newvaluej^ 
label name 

- the name of the data unit containing dm 

the name of the data member which is composed of the set of control 
statements to be executed 

- the field value which when encountered on a CS card image is to be 
replaced with the corresponding "new value". The old value may be 
any valid field type (I, RS, RD, L, AO, LO, N, A) recognized by the 
XCR module when cracking a card image. 

- the field value which will replace the "old value". The new ^ value 
may be any valid field type (I, RS, RD, L, AO, LO, N, A) described 
in Section 3.9, Table 1. The type of this old value does not have 
to be the same as the type of the new value; any field value may be 
replaced by any other field value. 

Each control statement (one or more card image records) on the member dm will be 
searched for fields which match the "old value" parameters specified on the CALL CS. If 
a field is found to match an "old value" then it is rep ced with the corresponding "new 
value". The types of "old value" and "new value" may or may not agree. 

After all replacements have been successfully accomplished, the set of control 
statements are executed sequentially beginning with the first CS in the dm member. Of 
course, execution flow sequence within the secondary control stream may be altered by a CS 
such as G0T0, IF, or another CALL. 


label 

du 

dm 

oldvalue 

newvalue 
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Upon completion of the set of CALLed control statements, execution will continue with 
the CS immediately following the CALL CS . 


Examples : 

LABEL CALL UN1( DM2 ) ,ANAME=BNAME ,10=15 $ 

CALL, UN2(DM2),3HABC=6HABCDEF, 10=15. 5 $ 

CALL UN3(DM3),. TRUE. =. FALSE. ,+=*,*=NAME $ 

Restrictions: du (dm) was previously created during this ANOPP run or on a previous 

ANOPP run with a fixed format of Cl (the normal procedure for creating du (dm) is via the 
DATA or UPDATE CS). 

3. 5. 2.4. 5 CONTINUE 


Purpose : The CONTINUE control statement allows for a no action step in execution 

It is used mainly with a G0T0 to allow processing flow alteration. 


Format : 

[label |J ]c0NTINUE $ 
label - label name 

Examples : 

LABEL1 C0NTINUE $ 

3. 5. 2. 4. 6 CREATE 


Purpose : The CREATE control statement defines an empty data unit on a direct access 

storage device for subsequent output of members . 


Format : 

[label J CREATE^du 1 [/efn 1 /] [. . . ,du n [/efn/] ] $ 
label - label name 

du - the name of the data unit to be associated with the data to be output 

on efn for this ANOPP run 

efn - the name of a file, known to the user, which is defined in the external 
system. If omitted, a scratch file name is assigned. 
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Examples : 

[L ABEL], CREATE UNIT1,UNIT2/EFN2/,UN3/E3/ $ 

CREATE UNIT2 $ 

Restrictions : The du and efn cannot respectively be the same as another data unit 

name or external file name currently entered in the data unit directory. 

3. 5. 2.4.7 DATA 

Purpose : The DATA control statement creates a data member on data unit DATA. 

Format : 

label. DATA ,DM=dmname $ 
d n 

label - label name 

dmname - the name of the data member to be created on data unit DATA. 

Data which is to form the data member, dmname, must immediately follow the DATA CS 
directive in the Primary Input Stream. The data card images must be terminated by an END* 
CS following the last card image to be used as data. 

Dmname will be written on data unit DATA. Dmname will have a fixed format of 10A8 
which corresponds to a card image. Each record on dmname will correspond to a single card 
image read from the Primary Input Stream. Any valid FORTRAN character is acceptable on 
the card image in any sequence except as follows: beginning with the first non-blank 

character, the first four (4) characters on a card image must not be END* as this is 
recognized as the DATA CS input terminator (i.e. , a card image beginning with END*AB is 
not an acceptable data card image ) . 

Examples : 

LABEL DATA DM = DMEM $ 

1 2 3 4 ... 50 

1.5 2.1 6.0 .TRUE. ... 40 

END* $ 

The data member DMEM will consist of two records of fixed format 10A8. Record 1 will 
contain the card image: 

1 2 3 4 ... 50 

3.5-10 


l 



EXECUTIVE MANAGEMENT SYSTEM 


Record 2 will contain the card image; 

1.5 2.1 6.0 .TRUE. ... 40 

Restrictions; The same name must not appear on another DATA CS within the same ANOPP 

run. 

3.5. 2.4.8 DETACH 


Purpose : The DETACH control statement removes a data unit from the set of data units 

known to the ANOPP run. The status of the external file associated with this data unit is 
left unchanged. 

Format : 

[label jDETACH <1 du 1 [...,du n ]$ 
label - label name 

du - name of the data unit known to the ANOPP run 

NOTE: Unless the data unit resides on a scratch file the external file is available for 

subsequent ATTACH CS statements. 


Examples : 


Ll DETACH AIRCR , AIRPRTS ,WC0N $ 
DETACH MSC $ 


3. 5. 2. 4. 9 DR0P 

Purpose : The DR0P control statement drops a sequential library file assigned to this 

job from the external system. The sequential library file is disassociated with the 
current execution. 

Format : 

[Label izl ]DR0P {a /sefn 1 /[... > /sefn n /] $ 
label - label name 

sefn - name of the sequential library files to be dropped. 


Examples : 

END DR0P /TAPE1/./TAPE2/ ,/FILEl/ $ 
DR0P /FLE/ $ 
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Restrictions : Sequential library file names (sefn) must be unique. 

3.5.2.4.10 ENDCS 

Purpose : The ENDCS control statement when processed terminates the ANOPP run. There 

must be only one ENDCS per run, and it must be the last control statement in the Primary 
Input Stream. It is the only control statement which will terminate an ANOPP run. 

Format : 

[label^] ENDCS $ 
label - label name 

Examples : 

ENDCS $ 

ST0P ENDCS $ 

Restriction : ENDCS is valid in the Primary Input Stream only. 

3.5.2.4.11 END* 

Purpose : The END* control statement indicates the end of the card image input stream 

required by the previous control statement, DATA, UPDATE or TABLE. 

Format : 

END* $ 

Examples : See DATA CS, UPDATE CS, and TABLE CS for specific examples. 

Restriction : END* is valid in the Primary Input Stream only. A label field is 

unacceptable on an END* CS. 

3.5.2.4.12 EXECUTE 

Purpose : The EXECUTE control statement defines a set of alternate names and executes 

a specified functional module. 

Format : 

[label^] EXECUTE fmname^[refname 1 =altname 1 , . . . ,refname=altname n ] $ 
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label - label name 

fmname - the name of the functional module which is to be executed, 
refname - the reference name which has a corresponding name 
altname - the alternate name corresponding to the reference name 

A set of reference names (refname) and corresponding alternate names (altname) is 
established (both refname and altname are valid name fields). The functional module is 
placed in execution immediately. During the execution, the set of alternate names is 
available for retrieval by the functional module or by an executive system module (for 
full explanation, see ANOPP Parameter Maintenance Functions (PMF) utilities. Member Manager 
Subprogram input arguments, and Table Manager subprogram input arguments). 

Examples : 

Ll EXECUTE JET A1=UAB,B=D $ 

EXECUTE JET $ 

Restriction : EXECUTE is valid in the Primary or Secondary Input Stream, fmname must 

refer to a functional module installed and recognized by the ANOPP executive system. 

3.5.2.4.13 G0T0 

Purpose : The G0T0 control statement allows an alteration in the flow of control 

statement processing. Processing will continue at the control statement containing the 

label specified. 

Format : 

[label^]G0T0^1abnam $ 

labnam - the label name of the control statement at which processing should 
continue 

Examples : 

NAME G0T0 NAME 2 $ 

G0T0 NAME $ 

Restriction : Labname must be in the label field of a control statement which is 

within the same set of control statements as this G0T0. 
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3.5.2.4.14 IF 


Purpose : The IF control statement permits an alteration in the flow of processing if 

a specified condition exists. The value of a user parameter is compared with the value of 
either another user parameter or a constant. If the comparison results in a true condition 
then processing continues with the control statement having the specified label; otherwise, 
processing continues with the next control statement. 


Format : 


[labelj]lF 


paramname 


logical 

^operator 


paramname ^ 

numerical constant 
logical constant 
string constant 


G0T0, labnam $ 

0 


label 

paramname ^ 
logical operator 


paramname ^ 
numerical constant 
logical constant 
string constant 

labnam 


- label name 

- name of a user parameter whose value is to be compared with 
the value following the logical operator 

- a logical operator used in comparison of the two values. 

Any logical operator is valid for comparing values which are 
type integer, real single precision, or real double precision. 
The operators .EQ. and .NE. are valid for values of types 
logical and character string 


the second value for comparison 


the label of the control statement at which processing 
should continue if the comparison of the two values results 
in a true condition. 


Examples : 


LABEL 


IF (A .GE. B) G0T0 LABEL1 $ 

IF (D .EQ. .TRUE.) G0T0 LABEL1 $ 
IF (F .EQ. 6HFVALUE ) G0T0 LABEL $ 


Restriction : Labnam must be in the label field of a control statement which is 

within the same set of control statements as this IF. The type of the second value must 
agree with the value type of paramname^ If the type is character string then the number 
of characters in the two strings must be equal. 
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3.5.2.4.15 L0AD 


Purpose : The L0AD control statement loads data units from a sequential library file 

which has been assigned to the run through the external operating system’s control langu- 
age. This sequential library file must have been created by an UNL0AD CS by the current 
or a previous ANOPP run. This CS provides selective loading and/or renaming of data units 
stored in a sequential library file. 


Format : 


[label.]L0AD/sefn/ $ 

[label^]L0AD/sefn/[dus 1> . . . ,dus n J $ where 

dus has the form: 

du|[/efn/] = odu [(d 1 , . . . ,d n )] j 

d. may have either of the forms: 
dm^ 


label 

sefn 

du 

efn 

odu 

dm 


dm 


new 


dm 


old 


dm - dm, 
new ola 

- label name 

- the sequential external file name of the library file from which data 
units are to be read 

- the name of the data unit which is to be loaded 

- the external file name 

- the name under which the data unit was unloaded. If not specified, it 
is assumed to equal du 

- the name of a data member on the odu which is to be loaded from the 
library. If a member list is not specified, all data members on odu du 
are loaded from the library 

- new name of data member 

- name data member was known by 


Examples : 


L0AD/TAPE1/ $ s 

L0AD/TAPE1/UNIT1/EFN1/ (MEM1 »MEM2 ) $ 
L0AD/TAPE1/UNIT2 ,UNIT3/EFN3/=0UNIT3 $ 


Restriction : du and efn must not be in the current data -nit directory. The name of 
the data unit to be loaded may not be XSUNIT or DATA. If duplicate data unit names 
appear on the left of the = , only one occurrence may specify the optional external file 

name (/efn/). 
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If data unit name stands alone, as in the form 

L0AD/LFN1/DUN1 $ or 
L0AD/LFN1/DUN1/EFN1/ $ 

then the data unit name (DUN1) may not appear on the right of the = again. 

There may be no duplicate data unit and data member name combinations on the right of 
the = . 


3.5.2.4.16 PARAM 


Purpose : The PARAM control statement establishes a user parameter or changes the 

value of an already existing user parameter. 


Format : 


[label ,3PAPAM .paramname = 


numerical constant 
string constant 
logical constant 
paramname^ 


or 


$ 


[label^] PARAM^paramname 1 =paramname 2^“|c! 


lumerical 

constant 


$ 


label 


label name 


paramname^ 

paramname^ 


a valid ANOPP name of the user parameter for which a value is to 
be established or changed 

a valid ANOPP name of a user parameter for which a value has already 
been set 


In the first form, paramname^ will be given the value following the equals sign. If 
paramname^ is specified, the current value of the user parameter paramname 2 will be used. 

In the second form an algebraic operation will be performed on two values which must 
be of the same type and the result will become the value of paramname^. The current value 
of paramname^ must be of the same type as the numeric constant. If paramname^ is the name 
of a previously established user parameter (via a PARAM CS or an XPUTP call), its value 
will be changed. The types of the old and new values may or may not agree. 

If paramname^ is not the name of a previously established user parameter, then a new 
user parameter is established and will remain available throughout the ANOPP run. A user 
parameter once established is never deleted from the set of known user parameters. 
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Examples : 

PARAM A=.5,B=A+10,C=D*2 $ 

PARAM F=C $ 

3.5.2.4.17 PR0CEED 

Purpose : The PR0CEED control statement allows for processing to continue at a 

specified point after an ANOPP error has occurred. It is used mainly in conjunction with 
the system parameter JC0N which may be set via the SETSYS control statement. When a 
control statement cannot process to its normal completion due to a non-fatal error condi- 
tion, processing will continue with the first encountered PR0CEED control statement if 
system parameter JC0N is set to .FALSE. . The PR0CEED , when encountered for execution by 
normal processing, is a no action step. 

Format : 

[label^J PR0CEED $ 
label - label field 


Examples : 


ERR1 PR0CEED $ 
PR0CEED $ 


Restriction : 


Upon encountering a non-fatal error. 


the control stream is searched for 


a PR0CEED statement. CALL statements encountered in this search are not expanded 


3.5.2.4.18 PURGE 

Purpose : The PURGE control statement removes a data unit (or units) from the set of 

data units known to the ANOPP Data Base Manager and also from the external operating 
system . 


Format : 

[label. ]PURGE^du 1 [ . . . ,du n ] $ 


label 

du 


label name 

name of the data unit to be purged 


name 
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Examples : 

APP PURGE UN1,UN2,UN4,UN5 $ 
PURGE UN6 $ 

3.5.2.4.19 RETURN 


Purpose : The RETURN control statement indicates processing of a Secondary Input 

Stream is complete and allows return to the calling Primary or Secondary Input Stream. 

Format : 

RETURN $ 

RETURN is created internally during the Secondary Edit Phase (see Section 3. 5.4.6) to 
indicate completion of the Secondary Input Stream". Upon processing a RETURN, execution 
will continue with the control statement following the CALL which initiated the execution 
of the Secondary Input Stream. 

Examples : Not applicable 

Restriction : RETURN is not allowed in the primary or secondary input stream provided 

by the user. It is simulated during the secondary edit phase for internal control only. 

3.5.2.4.20 SETSYS 


Purpose : The SETSYS control statement sets the value of a user system parameter. 


Format : 


[label^l SETSY S^sysparam^= value ^ [, . . . t sy sparam^s value^] $ 


label 


label name 


sysparam - the name of a user system parameter for which a value is to be set. 
A list is found in Table 2. SETSYS System Parameters Tkble. 

value - the value to which the corresponding user system parameter is to be 
set. The type of value must be valid and within range for the 
corresponding user system parameter 


A user system parameter may be set several times during the ANOPP run via a SETSYS 
CS. All user system parameters have initial value settings determined during the ANOPP 
Initialization Phase. The initial value is the default value defined by the ANOPP system 
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SYSTEM 

PARAMETER 

NAME 

DESCRIPTION 

TYPE/RANGE 

DEFAULT 

VALUE 

JC0N 

Controls Executive Managers action when 
an error has been detected in processing 
an ANOPP control statement. JC0N = .TRUE, 
indicates execution will continue with the 
next CS. 

Logical 

.TRUE. 

.FALSE. 

.FALSE. 


JC0N = .FALSE, indicates execution will 
continue with the next PROCEED CS. If a 
PROCEED is not encountered then the ENDCS 
CS will be executed for a normal termination. 



JECH0 

Controls printing of the CS card images 
upon validation in the Primary and Secondary 
Edit Phases. All of the Control Statements 
in the Primary input stream are edited for 
errors before execution of the first CS 
(Primary Edit Phase). All of the control 
statements in a data member which is called 
into execution via the CALL CS are edited 
for errors before execution of the first CS 
(Secondary Edit Phase). 

Logical 

.TRUE. 

.FALSE. 

.FALSE. 


JECH0 = .TRUE, indicates the CS images 
are to be printed 

JECH0 = .FALSE, indicates the CS images 
are not to be printed 



JL0G 

Controls printing of the CS card images 
upon execution in the AN0PP Control 
Statement Processing Phase. 

Logical 

.TRUE. 

.FALSE. 

. TRUE . 


JL0G = .TRUE, indicates the CS images 
are to be printed 

JBSH0 = .FALSE, indicates the CS images 
are not to be printed 




OK’CrX'.'li 5 fi-'vT. fr ; 

0.1F: J Tf-TvOV: A v T/-.'i ,TvS : : Table 2. SETSYS System Parameters 
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independent of user control. However, the default value of several system parameters may 
be set by the user during the Initialization Phase by the ANOPP CS. 

Examples : 

SETSYS JECH0= . TRUE . $ 

ABC SETSYS JC0N= . TRUE. , JL0G= . TRUE. $ 

3.5.2.4.21 STARTCS 

Purpose : The STARTCS control statement indicates the beginning of control statements 

in the Primary Input Stream. It is required for each ANOPP run. It immediately follows 
the ANOPP control statement, if present; otherwise, it must be the first card in the ANOPP 
Primary Iuput Stream. 

Format : 

.STARTCS $ 

Examples : 

STARTCS $ 

Restrictions : STARTCS is valid in the Primary Input Stream only. A label field is 

not allowed on the STARTCS. 


3.5.2.4.22 TABLE 


Purpose : The TABLE control statement builds a data table on a specified member, or 

subsequent use by Table Manager, from table description input cards. 


Format : 

[label^]TABLE^du(dm)^type^SOURCE=srce $ 


label 

du(dm) 

type 

srce 


label name 

specifies the name of the unit and member on which the table is to be 
built 

specifies the type of table to be built. A present type must be 1 
(see Section 3.4. 3.1 for description of Table Type 1) 

specifies the location of the table description card images 
may assume one of two forms: 

* card images follow in input stream; 

du(dm) card images reside on the specified unit member in card image 
(Cl) format 
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The table type 1 table description cards are of the following format. 
INT = Cl,... 

IND = FC ,NV,EXU ,EXL,VAL1 ,VAL2 , * . . 

DEP n = FC,VAL1 ,VAL2 , . . . 


where : 

INT card - contains the integer codes for the interpolation procedures permitted 
on this table. 

Cl - Integer code 

0 - no interpolation permitted 

1 - linear interpolation 

IND card - contains the description of the nth independent variable where l-n-3. 

FC - (format code) the alpha data type code of the nth independent 

variable. . _ 

0 - ordered position from 1 to NV; independent variable values 

not entered 

1 - integer 

RS - real single precision 
RD - real double precision 

NV - number of values for the nth independent variable 

EXU - integer code for the extrapolation procedure to be use ( y 

interpolation routines) if the independent variable is greater 
than the largest independent variable 

0 - no extrapolation allowed 

1 - use the independent value closest to the specified value 

2 - extrapolation is linear using the last two independent 

values 

EXL - integer code for the extrapolation procedures to be used it 

the independent variable is less than the smallest independent 
variable. See EXU for code value # . 

VAL1 - NV values for the nth independent variable in ascending or 

descending order. Values are separated by blank or comma and 
may extend over several card images. If FC=0, values are not 
included. 

DEP card - contains the description and values of the dependent variable and must 
follow the INDN cards. 

FC - (format code) alpha data type of dependent variable 
I - integer 

RS - real single precision 
RD - real double precision 

VAL1 - values for the dependent variable separated by commas or blanks . 
May extend over several card images. The order of dependent 
variables is such that the first independent variable varies 
first, the second variable varies second, and the third variable 
varies third. 

END* card - required if source = *. 
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Examples : 

LAB TABLE UNI(DMS) ,1,S0URCE=* $ 

INT =0,1 

IND2 = 1,2,0,1,5,10 

IND1 = RS, 3, 0,1, 1.5, 2*0,4. 5 

DEP = I, 3, 5, 7, 8, 9 

END* $ 

TABLE UN2(DM1),1,S0URCE=UN5 (DM2) $ 

Restriction : TABLE with S0URCE=* is valid in the Primary Iuput Stream only. TABLE 

with S0URCE=DU(DM) is valid in the Primary or Secondary Iuput Stream. 

3.5.2.4.23 UNL0AD 

Purpose : The UNL0AD control statement unloads data units , known to the present ANOPP 
run, to a sequential library file which has been defined and assigned to the run through 
the operating system control language. 

Format : 

[label^]UNL0AD/sefn/ (dus^,. . .dus^] $ 

where dus is of the following form: 
du [( dm^ , . . . dm^ ) ] 

label - label name 

sefn - the sequential file name of the library file to which data units are to 
be unloaded 

du - the name of the data unit to be unloaded 

dm - the name of the data member to be unloaded. If a data member is not 

specified, all of the data members on the data unit are unloaded 

If a data unit list is not specified, all data units presently defined in the Unit 
Directory except XSUNIT and DATA will be unloaded to sefn. The Unit Directory consists of 
all units which have been L0ADed, ATTACHed, or CREATed, and have not been DETACHed or 
PURGed since the beginning of the ANOPP run. 

Examples : 

UNL0AD/TAPE1/ $ 

UNL0AD/TAPE1/UNIT1 ,UNIT2(MEM1) $ 

Restrictions : There may be no duplicate data unit and data member name combinations. 
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3.5.2.4.24 UPDATE 

Purpose : The UPDATE control statement provides a means of building a data unit by 

using an existing data unit as a basis for modifications or by adding members from various 
sources with no one data unit as a basis or a combination of both. There are two UPDATE 
modes, revise and create, depending on the presence of a data unit as a basis for revi- 
sion. For more detailed information concerning UPDATE, see Section 3.8. 


Format: 


[label jfr )uPDATE {} [0LDU=du 1 d ] NEWU=du 2 ^ [ALL d ]S0URCE=j d 


du„(dm 0 )| 
o o 


r« [*...]] 


label name 


du - the name of the data unit to be used as the basis for UPDATE pro 

d 1 cessing. The presence of the OLDU clause indicates a revise mode 

UPDATE. Member level and record level directives which allow a 
default of OLDU data unit or imply the OLDU data unit, will u du i» 
as the required unit. The omission of the OLDU clause indicates a 

create mode UPDATE. 

du - the name of the new data unit to be built during UPDATE processing. 

J - this keyword indicates a full update of the basis data unit (OLDU) is 

to be performed. All data members on the OLDU data unit which are not 
processed by a member level directive will be copied to the NEWU data 

unit. 

SOURCE C1.US, - th. SOURCE clause specifies where the set of UPDATE input directives 

^indicate^the directives follow i~ediately.it! the Primary Input 
Stream with the set of UPDATE directives terminated by an END- Li, . 
du (dm 3 ) indicates the directives are found on the data unit and 
member specified 

UST clause - specifies 

thf sections of output desired. The list may be any combination of 

the following: 

E - Directive Echo Section 
S - Summary Section 
C - CHANGE Members Section 
A - ADDR Members Section 
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Examples ; 

LABI UPDATE NEWU=U1 ,S0URCE=*,LIST=S $ 

(directive set) 

END* $ 

UPDATE 0LDU=UOO1 ,NEWU=U002 ,ALL,S0URCE=DUS(M1) ,LIST=SEA $ 

UPDATE 0LDU U002.NEWU ABC,S0URCE=* $ 

(directive set) 

END* $ 

UPDATE ALL,0LD=UN1,NEW=UN2,S0URCE=*,LIST=A $ 

(update directives) 

END* 

UPDATE NEW=UN3 ,S0URCE=UN4( MEM1 ) $ 

Restrictions : See UPDATE Description (Section 3.8). 
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3.5.3 Executive Monitor (XM) 

Purpose : The Executive Monitor (XM) module is the single driver for the Executive 

Management System. XM is also the main FORTRAN program for ANOPP and remains in core at 
all times. It is in ultimate control of ANOPP from beginning to end and thus directs the 
execution of other Executive Management System modules to accomplish the tasks required. 

XM calls into execution five of the Executive Management System execution phases. These 
phases are the Initialization Phase, the Primary Edit Phase, the Control Statement Pro- 
cessing Phase, the Functional Module Processing Phase, and the Error Processing Phase. 

The remaining execution phases are called into execution as required during these phases 
by lower level modules. 

Input : Since XM is a driver module to direct execution of various execution phases, 

there is no direct input. 

Output : Since XM is a driver module there is no output. All output from ANOPP is 

accomplished within the various execution phases. 

Functional Description : The functions of XM are as follows: 

1. lb perform initialization requirements for the Executive Management System, the 
Data Base Management System, the Dynamic Storage Management System, and the 
General Utilities (Initialization Phase). 

2. To validate the ANOPP execution sequence defined by the Primary Input Stream 
(Primary Edit Phase). 

3. To execute or process the execution sequence to completion (Control Statement 
Processing Phase). 

4. To execute or process Functional Modules (Functional Module Processing Phase). 

5. To direct the action to be taken upon encountering a non-fatal error during 
execution of the Control Statement or Functional Module Processing Phase (Error 

Processing Phase). 

Logical Description : XM calls into execution the Initialization Phase, and the 

Primary Edit Phase and then iterates between the Control Statement Processing Phase and 
either the Functional Module Processing Phase or the Error Processing Phase. 

At the beginning of ANOPP the driver XM is brought into execution and XM immediately 
calls XLINK requesting that the module XBS be executed. XBS controls the Initialization 
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Phase. Initialization requirements for all executive modules are performed according to 
parameter values specified on the optional ANOPP CS in the Primary Input Stream or default 
values provided by the ANOPP installation settings. 

Upon completion of XBS, XM calls XLINK requesting that XRT be executed. The module 
XRT controls the Primary Edit Phase. The control statements in the Primary Input Stream 
following the STARTCS are read* validated, reformatted into an executable form, and 
written as data member M001. This member resides on the data unit XSUNIT which is re- 
served for Executive Management System usage. The reformatted control statements residing 
on M001 are called the Primary CS Set. XRT does not return to XM if during the Initializa- 
tion Phase or the Primary Edit Phase an error has occurred; XRT will call the Error 
Termination Phase to abort ANOPP. 

Upon completion of the Primary Edit Phase, XM calls XCSP via XLINK. The XCSP module 
controls the Control Statement (CS) Processing Phase. The Primary CS Set is executed or 
processed sequentially allowing for flow alteration by certain control statements. A 
Secondary Input Stream may be called into execution via a CALL CS. Upon the first execu- 
tion of a particular CALL, the Secondary Input Stream is read, validated, reformatted, and 
written in executable form as an Mxxx type data member residing on the XSUNIT data unit. 

The name Mxxx, where xxx is an integer sequentially assigned as required, is assigned to 
the data member. This data member is called a Secondary CS Set. XCSP continues to 
execute the Primary and Secondary CS Sets to completion unless a non-fatal error is de- 
tected or execution of a Functional Module is requested via an EXECUTE CS. In either 
case, control is returned to XM for action. 

Upon return from XCSP, XM determines the reason for interruption of the CS Processing 
Phase. The ANOPP error indicator, variable NERR residing in /XCVT/, is interrogated and 
if errors occurred, the module XMERR is called via XLINK to perform the Error Processing 
Phase. If errors occurred then the XFM module is called directly by XM to perform the 
Functional Module (F.M.) Processing Phase. 

During the Error Processing Phase, depending on the system parameter JC0N, XMERR will 
provide the environment for the next entry to XCSP to either continue processing with the 
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next CS or to continue processing with the first PR0CEED CS found in a sequential scan 
forward from the CS which encountered the error. No control statements are executed 
during the scan. In particular, a call statement is neither expanded nor processed. If 
no PR0CEED is found in the search, XMERR provides the environment to continue processing 
with the ENDCS in the Primary CS Set; this will subsequently invoke the Normal Termination 
Phase upon the next entry to XCSP. 

Upon return to XM from XMERR, the module XCSP is called to proceed with the CS 
Processing Phase. 

During the Functional Module Processing Phase, XFM brings into execution the re- 
quested Functional Module (F.M.). Upon completion of the F.M. the integrity of the ANOPP 
system environment is validated and insured by XFM taking corrective action as required. 

Upon return to XFM, XM interrogates the ANOPP error indicator NERR to determine non- 
fatal error occurrence during the F.M. Processing Phase. If error occurrence is detected 
then XMERR is called via XLINK to perform the Error Processing Phase. Upon return from 
XMERR, XM calls XCSP to proceed with the CS Processing Phase. 

After once calling XBS and XRT, XM cycles between calling XCSP and XFM or XMERR. 

Error Philosophy : No error is detected directly within the driver XM. However, 

error detection does occur within the execution phases called into execution by XM. If a 
fatal error, which inhibits recovery with further processing, is detected then ANOPP is 
abnormally terminated via the Error Termination Phase and there is no return to XM. If a 
non- fatal error is detected within XBS, the indicator NERR is set. XM does not detect 
this error return from XBS and allows XRT to be called. XRT upon completion will recognize 
error occurrence during execution of XBS or itself and will abnormally terminate via the 
Error Termination Phase. If a non-fatal error is detected within XCSP or XFM then the 
NERR indicator is set and action is taken upon return to XM. 
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3.5.4 Execution Phases 


The Executive Management System (EM) includes eight execution phases corresponding 
respectively to the eight tasks given in the Overview Section (Section 3.5.1). These 
phases, along with the controlling EM Module, are as follows: 

1. Initialization Phase (XBS) 

2. Primary Edit Phase (XRT) 

3. Control Statement Processing Phase (XCSP) 

4. Functional Module Processing Phase (XFM) 

5. Error Processing Phase (XMERR) 

6. Secondary Edit Phase (XCA) 

7. Normal Termination Phase (XEN) 

8. Error Termination Phase (XXFMSG) 

3. 5.4.1 Initialization Phase (XBS) 

Purpose : The XBS Module controls the Initialization Phase. The ANOPP Title Page is 

printed and all initialization requirements for DBM, DSM , EM, and the General Utilities 
are performed. 

Ingut: Input to XBS is the Primary Input Stream which contains the optional AN0PP 

CS and the required STARTCS CS. 

Output : 

1. Data Base Structures 

XSUNIT - the data unit created for subsequent usage by the Executive Manage- 
ment System (EM) for scratch data members temporary to ANOPP. 

DATA - the data unit created for subsequent usage by EM in processing the 
DATA control statements. 

2. Common Block Variables 

Required variables in the following common blocks are initialized: 

/XCS/, /XCSFM/ , /XCVT/ , /XDBMC/ , /XDSMC/ , /XSPT/. 

3. Control Structures 

The following Control Structures are allocated and initialized in Global 
Storage : 

Alternate Name Table (ANT) 

Data Unit Directory (DUD) 
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Member Description Blocks Table (MDBT) 

User Parameter Table (UPT) 

User String Table (UST) 

Active Member Directory (AMD) 

Data Table Directory (DTD) 

Library File Directory (LFD) 

Member Directory (MD) work area 

Functional Description : The XBS module performs the ANOPP Initialization Phase 

requirements. The Primary Input Stream is processed through the STARTCS control state- 
ment. If the optional AN0PP CS is present, the values specified for the ANOPP system 
parameters replace the ANOPP system default values for subsequent initialization pro- 
cedures. If the AN0PP CS is omitted, the ANOPP system default values are used for sub- 
sequent initialization procedures. 

DSM initialization requirements include setting parameter values in the common block 
/XDSMC/ and initializing Global Dynamic Storage according to the length required. 

DBM initialization requirements include setting parameter values in the common block 
/XDBMC/ , creating the data units DATA and XSUNIT for EM utilization, and allocating 
required control structures. These control structures are the DUD, DTD, AMD, and LFD. A 
working storage block for the MD is also allocated. The DUD and DTD contain information 
which must not be moved to other core locations when DSM consolidations occur; thus the 
DUD and DTD are the first allocated blocks in GDS. 

EM initialization requirements include setting parameter values in the common blocks 
/XCVT/ , /XCS/, /XCSFM/ , and /XSPT/. The following control structures are allocated and 
initialized in GDS: MDBT, ANT, UPT, and UST. The ANT is initialized for zero allocated 
entries. The others are initialized using installation default values. 

There are no additional initialization requirements imposed by the General Utilities 

Logical Description : XBS performs initialization functions for EM and calls four 

additional modules to perform the remaining Initialization Phase requirements. 

Immediately upon entry the module XBSTP is called to print the standard ANOPP title 

page. 

: Jkl- 
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The module XBSIN is then called by XBS to determine the presence or absence of the 
AN0PP CS in the Primary Input Stream and to initialize parameters according to either the 
AN0PP CS specification or the installation default values. Detection of the STARTCS in 
the Primary Input Stream is also accomplished. 

The module XBSDSM is called by XBS to initialize Global Dynamic Storage according to 
the length specified either by the AN0PP CS or by the installation default value. 

The module XBSDBM initializes the Data Base Management System Control and data base 
structures. The Data Unit Directory (DUD) and Data Table Directory (DTD) are insured to 
be the first blocks allocated in GDS. They are not expandable tables and thus are al- 
located for fixed numbers of entries which may not be exceeded during ANOPP execution. 

The AMD, MD, and LFD control structures are allocated according to parameterized default 
values. The data units, XSUNIT and DATA, are created with corresponding entries made in 
the DUD. 

Upon completion of DSM and DBM initialization, XBS allocates the EM control structures 
which include the MDBT, ANT, UPT, and UST. An entry in the MDBT is allocated for the 
Primary CS Set, or M001 member, and the entry is initialized. Alternate names exist only 
during the Functional Module Processing Phase, thus the ANT is allocated for zero-entries. 
The UPT and UST are allocated according to installation default values. 

XBSTP , XBSIN, XBSDSM, and XBSDBM are the primary modules called by XBS to perform 
Initialization Phase functions* 

g£T.?F, Philosophy: If an error occurs in allocating or initializing any control or 

data base structure, then ANOPP is abnormally terminated. Fatal errors encountered while 
initializing DBM and DSM are processed respectively via the member manager module MMERR 

and the DSM module DSMERR. Other fatal errors invoke the EM Error Termination Phase for 
processing. 

An error encountered in processing the AN0PP CS is not immediately fatal. The 
Initialization Phase continues to completion and the ANOPP error indicator, NERR, is set 

to .TRUE, upon exit from XBS. ANOPP is subsequently terminated upon completion of the 
Primary Edit Phase. 
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3. 5.4.2 Primary Edit Phase (XRT) 

pumps,, : The Primary Edit Phase <XRT> module is called by the Executive Monitor <»> 

module after the Initialisation Phase <XBS> module has completed its task. The Primary 
Edit Phase examines and validates control statements in the Primary Input Stream and 
build, a record for each CS on the root member, 11001, in a format that is recognised by 
the Control Statement Processing Phase (XCSP). The Primary Edit Phase allocates a new 
„xxx member name in sequential order each time a CALL CS is encountered in the Primary 
input Stream beginning with HOOP, a Hember Description Block entry (HDD) is initialised 

„ , . p-pimarv Edit Phase builds a Uxxx type member 

in the MDBT for the Mxxx just allocated. The Primary bait rn 

each time an UPDATE or a TABLE CS is encountered with a SOURCE-* specification. The 
SOURCE-* specification indicates that input expected for the particular CS .ill be found 
in the input stream, beginning «ith the card image i«..di.tely following the CS and includ- 
ing all images down to but not including the END* CS. Upon completion of its task, the 
Primary Edit Phase will terminate ANOPP processing if an error was detected in the Initi- 
alisation Phase prior to XRT entry or in the Primary Edit Phase, or if the user option to 
terminate after Edit Phase is set. Otherwise, the Primary Edit Phase will return control 

to the Executive Monitor (XM). 

lnput : The primary input to the Primary Edit Phase (XRT) is the Primary Input Stream 

which begins with the control statement following the STARTCS statement and ends with the 
ENDCS statement. Other pertinent input is described below; particular input required for 
CS processing is not necessary for understanding and is not included. 

Si?"- S Se C S S F system scratch unit, XSUNIT, contains no members. 

DATA - the DATA unit contains no members. 

2. Common Block Variables 

indicator is^set to .FALSE, the Primary Edit Phase returns to XH 
upon completion. 

deS“«“i«“^uSi°h SJTiSs)'^ o. f s‘”of 
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such an error, XRT edits and builds CS records but suspends writing 
of those records to the M001 member. At completion of the Primary 
Edit Phase processing will be terminated. 

3. Control Structures 

MDBT - the Member Description Block Table resides in GDS and is a system 
table type 1. An entry (MDB) in the MDBT is initialized for the 
M001 root member. Initial settings in the MDB indicate that the 
M001 root member has yet to be constructed. 

Output : 

1. Data Base Structures 

M001 - The primary output of the Primary Edit Phase is the Primary CS Set 

residing as the M001 root member on XSUNIT in a format that is 
recognized by the Control Statement Processing Phase. M001 contains 
a variable length control statement (CS) record for each complete 
CS edited in the Primary Input Stream and a Label Record that 
provides a cross-reference to each labeled CS on the MODI member. 

If an error is detected, writing to the M001 member is suppressed, 
but editing continues to the last CS in the Primary Input Stream. 

Uxxx - A Uxxx type data member in card image (Cl) format resides on XSUNIT 
unit for each UPDATE CS or TABLE CS with S0URCE=* specification 
encountered in the Primary Input Stream. A Uxxx type data member 
resides on DATA unit for each DATA CS encountered in the Primary 
Input Stream. The Uxxx contains the card image input to the CS 
which will be utilized in subsequent execution of the CS. 

2. Common Block Variables 

/XCS/ 

MEMCUR - The current member in execution is defined by MEMCUR as M001. 

/XCVT/ 

NERR - On exit from the Primary Edit Phase (XRT) the executive system 
logical error indicator is always set to the no error condition 
of .FALSE. 

3. Control Structures 

MDBT - The Member Description Block entry for the (MDB) M001 root member is 
in executable format. Also, an MDB entry is initialized for each 
Mxxx type member name assigned as a result of a CALL CS successfully 
edited in the Primary Edit Phase. Initial values in the MDB indicate 
that the Mxxx member has yet to be constructed. 


Functional Description : The XRT module performs all operations necessary in con- 

structing the M001 root member. The Primary Input Stream is processed beginning with the 
control statement that follows the STARTCS control statement. Processing terminates when 
the ENDCS control statement is encountered. An unformatted variable length control state- 
ment record is built for each complete control statement image in the Primary Input Stream. 
The control statement records are written on the MO 01 root member unless an error is 
detected. If an error occurs, writing on the M001 member is suppressed, but editing and 
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building CS Records continues until the ENDCS control statement is encountered. A Label 
Record is built identifying the number of every CS Record where a label is present and 
giving the label name. The Label Record is written as the last record on the M001 root 

member . 

As the Primary Input Stream is processed and the control statement records are 
built, the control statement images are echoed if the system parameter JECH0 is set to 

.TRUE, or an error is detected in building the CS Record. If an error is detected in 

building the M001 member, the system parameter JECH0 is automatically set so that sub- 
sequent CS images will be echoed, and writing on the M001 member is inhibited. A control 
statement is considered in error under any of the following circumstances: 

1. The maximum number of continuation cards allowed per CS is exceeded. 

2. An unrecognizable field is detected on the CS image. 

3. The form of a label field is invalid or a duplicate label is detected. 

4. CS name is invalid to the Primary CS Set. 

5. Syntax of the CS is invalid for the corresponding CS name. 

If a CS image exceeds the maximum allowable card images for a valid CS, the control 
statement is arbitrarily terminated at the end of the last allowable image and processing 
continues as it would for a valid CS Record. The image immediately following this CS in 
the Primary Input Stream will be read and processed as the next CS image. 

A syntax check is performed on each Control Statement Record to insure that the 
format of the CS meets the requirements of the particular CS name. 

All references to CS labels are verified. CS names valid to the Primary CS Set 
require special processing during the Primary Edit Phase. All label references on the IF 
and G0T0 control statements are entered in the Label Reference Table maintained by the XRT 
module. When all control statements have been processed the table is used to validate 
that all labels which have been referenced are present in control statements m the 
Primary Input Stream. 

A comment CS is one in which the end-of-data character ($) is the first non-blank 
character on the CS image. A comment control statement is included as a CS Record with 
C0NTINUE substituted as the CS name. 


3.5-33 



EXECUTIVE MODULES 


A DATA CS is processed completely in the Primary Edit Phase. C0NTINUE is substituted 
as the CS name in the CS Record and the images following the DATA CS in the Primary Input 
Stream down to the END* CS are written as a data member on the system unit DATA in card 
image (Cl) format. The END* CS which indicates the end of input for the DATA member is 
not included on the member. The data member name is specified on the DATA CS. 

For each CALL CS encountered in the Primary Input Stream, an Mxxx data member name is 
assigned and an MDB entry is made in the Member Description Blocks Table with initial 
settings. The initial setting indicates the Mxxx member has not been constructed and does 
not exist on XSUNIT. Mxxx data member names are assigned sequentially where the xxx 
portion of the name is Hollerith digits 002-999. The Mxxx member will be constructed 
during the Secondary Edit Phase upon the first execution of the CALL CS in the CS Pro- 
cessing Phase. 

The UPDATE and TABLE control statements require special processing when S0URCE=* is 
specified. The S0URCE=* specification indicates that input for the UPDATE or TABLE follows 
the CS in the Primary Input Stream and includes all images until an END* CS is detected. 
These card images are saved on a Uxxx member with one card image per record in Cl format. 

A Uxxx type data member is built on the system data unit XSUNIT each time such an UPDATE 
or TABLE CS is detected. Uxxx member names are assigned sequentially with the xxx portion 
of the name being Hollerith digits 001-999. 

If any CS requiring special handling of the card images immediately following in the 
input stream (DATA, TABLE, or UPDATE) is in error, then the images in the input stream 
will be skipped through the END* CS and will not be processed as described above. 

The M001, root member, is considered in error if a control statement in the Primary 
Input Stream is found to be in error or if an unsatisfied label reference is detected. 

When the M001 member is considered in error, writing to all data units (XSUNIT and DATA) 
is suspended as indicated above. 

Detection of the ENDCS control statement indicates the end of the Primary Input 
Stream. If the end of the input file is detected before the ENDCS statement is encountered. 
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and ENDCS statement is simulated for complete recovery. The XRT module makes a normal 
return if all of the following conditions are met: 

1. Primary Input Stream processing is complete (an ENDCS Control statement is 
detected or simulated) 

2. The M001 root member is error free (no error was detected on any edited con- 
trol statement) 

3. The user option to terminate after Primary Edit Phase (N0G0) is not set. 

4. The Initialization Phase was error free. 

If all of these conditions are not met, the XRT module aborts upon completion of 
Primary Iuput Stream processing. 

Logical Description : Immediately upon entry to the XRT module, the XRTI module is 

called to allocate and initialize expandable Local Dynamic Storage blocks required to 
build the Control Statement Record, the Label Record, and the Label Reference Table, and 
to initialize appropriate variables in the /XR00T/ common block. The CS Record block is 
allocated to build the maximum length CS Record. The Label Record and Label Reference 
blocks are allocated for an arbitrary number of label entries. 

The XRT module then opens the M001 root member for write via scratch access and 
begins to process the Primary Input Stream. The following process is iterated for each 
control statement read until the ENDCS statement is encountered. 

A. The XCR module is called to crack each image read from the Primary Input 
Stream. XCR builds a table from each image that includes every field detected 
on the CS image preceded by an integer type code field identifying the field 
as one of the ANOPP field types. 

B. If the maximum number of images per CS is read and the end-of-data character 
($) is not detected the XRTTC module is called to simulate a complete control 
statement as if it is complete. 

C. The XRTBAD module is called if unrecognizable fields are detected on the 
current control statement. XRTBAD prints each unrecognizable field found on 
CS. 

D. The XRTBCS module is then called to build a valid control statement record 
from the cracked table produced by XCR. XRTBCS strips off the first, and 
possibly the second, field in the cracked field table looking for a valid label 
name field, if present, and a CS name valid to the Primary CS Set. The label 
name, if present, and the CS name are entered in the CS Record. Upon exit 
from XRTBCS, the CS Record is complete and is read to be written on the M001 
root member. 
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E. If a valid label field was detected by XRTBCS then the XRT module calls 

XRTBLR module to add an entry to the Label Record. Each entry in the Label 
Record identifies the number of the CS record and the label name. 


F. If the CS is still error free after the syntax check, XRT calls XRTLRF module 
to pick up label references from IF and G0T0 control statements. Label 
references are entered in a single-word entry in the Label Reference Table. 

G. XRT then echoes the CS image if the user print option JECH0 is set or if 
an error was detected in the current CS or a previous CS. 


The XRTCSS module is then called to process the special CS names, DATA, CALL 
UPDATE, and TABLE. A DATA control statement is processed completely, sub- 

C0NTINUE as the CS name in the CS Record Preface, and writing data 
/oT\ t .c 0n the spec ^ f:; ‘' ed da ta member on the system unit named DATA in card image 
(Cl) format. For a CALL CS an Mxxx data member name is assigned and the member 
name is entered in the CALL CS Record Preface. A corresponding MDB entry is 
"! ade , and initialized in the MDBT. Special processing is required for the 
UPDATE and TABLE statements if S0URCE=* is specified. For these control state- 
ments a Uxxx member name is assigned, input for the CS is written on the 
member in Cl format , and the Uxxx member name is entered in the UPDATE or TABLE 

CS Record Preface. Upon exit from the XRTCSS module all special CS processing 
is complete. & 


I. Current CS processing is now complete and the CS Record is written on the M001 
root member if the Primary Input Stream has been error free and there were no 
Initialization Phase Errors, 


Primary Input Stream processing is complete when an ENDCS control statement is edited 
and the corresponding CS record placed on M001. Then the XRTLSA module is called to 
validate that all label references (found in the Label Reference Table) have been satis- 
fied. If all label references are satisfied then the XRT module writes the Label Record 
on the M001 root member as the last record and enters the label record length in the 
member description block entry in the MDBT for the M001 root member. 

The M001 root member is now complete and is closed by the XRT module. XRT then 
defines M001 as the Mxxx member now in execution by setting the output variable MEMCUR. 

The XRTRS module is then called to free the Local Dynamic Storage blocks used for building 
the CS Record, the Label Record, and the Label Reference Table and to release Local 
Dynamic Storage. 

If an error was detected in the Initialization Phase or while building the M001 
member, or if the N0G0 parameter is set to .TRUE., then XRT aborts. Otherwise, a normal 
return is made to XM, 
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Error Philosophy : The Primary Edit Phase aborts via XXFMSG fatal message writer if 

an error is detected while opening the M001 root member or if there is insufficient Local 
Dynamic Storage to expand any of the XRT expandable LDS blocks . 

A missing ENDCS control statement in the Primary Edit Phase does not make further 
processing impossible, so in such a case, an ENDCS statement is simulated for complete 
recovery . 

Errors detected in the Primary Input Stream while building the M001 member are not 
immediately fatal. Errors detected in the Primary Edit Phase will result in error messages 
printed before the appropriate CS image is echoed, will inhibit writing to the M001 member, 
and will result in an error flag setting for the M001 member. Editing and building CS 
Records will continue until the Primary Input Stream has been completely processed, and 
XRT will then abort the Primary Edit Phase. 
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3. 5.4. 3 Control Statement Processing Phase (XCSP) 

Purpose : The XCSP module controls the Control Statement (CS) Processing Phase. The 

Primary Input Stream is executed from beginning to end allowing for execution of optionally 
supplied Secondary Input Stream(s). This phase is temporarily interrupted with return to 
the driver XM whenever either a non-fatal error is encountered or execution of Functional 
Module is requested. 

Input : The primary input to XCSP is discussed below. Additional input, although 
required for particular CS processing, is not necessary for understanding and is not 
included. 

1. Data Base Structures 

XSUNIT - The unit XSUNIT contains Mxxx members and Uxxx members where xxx 
is display code of an integer 001-999. M001 is the Primary CS 

Set or root member and is always present. There is an Mxxx member 
where xxx is greater than 001 for each Secondary CS Set which has 
been brought into execution at least once via a CALL CS. There is 
no limit to the number of Mxxx members which may be in completed 
execution or suspended execution but there is one and only one 
Mxxx which is in current execution. A Secondary CS Set is in 
completed execution if it has been brought into execution via a 
CALL CS and execution has been completed. A Primary or Secondary 
CS Set is in suspended execution if its execution has been 
temporarily interrupted by a Secondary CS Set brought into execution 
via a CALL CS. A Primary or Secondary CS Set is in current 
execution if it contains the next CS to be executed. Any Mxxx 
member in current or suspended execution contains at least one CS 
record to be executed. For M001 this is the ENDCS CS and for 
Mxxx it is the RETURN CS. A Uxxx member exists for each TABLE 
CS and for each UPDATE CS with S0URCE=* specification in the 
Primary CS Set. All Mxxx and Uxxx members are closed. 
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DATA - The Unit DATA contains a member corresponding to each DATA CS 

encountered in the Primary Input Stream during the Primary Edit 
Phase . 


2. Common Block Variables 

/xcs/ 

MEMCUR - name of the Mxxx member in current execution 

MXMDB - IDX of the Member Description Block Table (MDBT) residing in GDS 

MNAME ,MCUR ,MCALL ,MRL ,MLL - position parameters for a Member Description 
Block (MDB ) which is an entry in the MDBT 

/XCSFM/ 

LANT - IDX of the Alternate Names Table (ANT) residing in GDS 

LUPT - IDX of the User Parameter Table (UPT) residing in GDS 

LUST - IDX of the User String Table (UST) residing in GDS 


3. Control Structures 

MDBT - the Member Description Block Table (MDBT) resides in GDS and is 

a System Table Type 1 which contains a Member Description Block 
(MDB) entry for each Mxxx name assigned. 

ANT - the Alternate Names Table (ANT) is a System Table Type 1 residing 

in GDS, which defines the active set of alternate names. It ^always 

has zero entries on entry. Alternate names provide only an inter- 
face capability between the F.M. and the CS Stream being executed 
and thus exist only during the F.M. Processing Phase. 

UPT/UST - the User Parameter Table (UPT) is a System Table Type 1 and the 

User String Table (UST) is a System Table Type 2; both reside in 
GDS. The UPT and UST in combination define all user parameters. 
There is an entry in the UPT, and UST if required, for each user 
parameter currently defined. 


4. Initial Entry 

For the initial entry to XCSP the following environment exists: 

a. XSUNIT contains the M001 member and Uxxx members may or may not exist. 

b. DATA may or may not contain members. 

c. MEMCUR contains the name M001. 

d. The MDBT contains an executed MDB for M001 with the MNAME position 
M001, MCUR position = 0, MCALL position = blanks, MRL position> 0, and 
MLL position > 0. 

e. The UPT, UST, and ANT contain zero entries. All data members are closed 


Output : 

1. Data Base Structures 

All members on the units XSUNIT and DATA are closed. 


original page 
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2. Common Block Variables 

The primary output from XCSP upon return to the XM driver is definition of 
the reason for CS Processing Phase interruption and definition of the specific 
CS in a CS Set with which processing will continue upon resumption of the CS 
Processing Phase. This information is provided through common block variables. 


/XCVT/ 

NERR 


/xcs/ 

REQ 


MEMCUR 

MXMDB 


the logical ANOPP error indicator. It is set to .TRUE, if a non- 
fatal error occurred during processing a CS thus causing the 
interruption; otherwise it is .FALSE. 


if an EXECUTE CS precipitated the interruption of XCSP then REQ 
contains the integer corresponding to the specific Functional 
Module (F.M.) requested. Integer and F.M. correspondence is 
determined upon F.M. installation. 

the name of the current Mxxx member being executed. 

the IDX of the MDBT in GDS. The current CS record pointer (MCUR) 
in the MDB entry for the current Mxxx member is set to the CS 
record resulting in the interruption. 


Functional Description : The CS Processing Phase begins with execution of the first 

CS in the Primary CS Set which is contained on the M001 member on XSUNIT. Execution of 
subsequent control statements in the Primary CS Set is sequential through the final CS 
which is the ENDCS. The sequential flow, however, may be altered by special control 
statements which transfer execution to a labelled CS within the Primary CS Set. One such 
CS is the G0T0. After such an alteration, sequential execution is resumed, thus the ENDCS 
is eventually executed. Execution of the ENDCS invokes the Normal Termination Phase which 
terminates ANOPP. 


Execution of the M001 member is temporarily suspended upon execution of a CALL CS. 

The CALL CS requests that a Secondary Input Stream be brought into execution and completed 
before continuing execution of the current M001 member. 

Upon the first execution of a CALL CS, the corresponding Secondary CS Set has not yet 
been constructed and does not exist on XSUNIT as a Mxxx member. However, during the 
Primary Edit Phase when M001 was constructed, an Mxxx name was assigned for each encoun- 
tered CALL CS and a corresponding MDB entry in the MDBT was allocated. The MDB entry has 
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initialized settings which indicate the corresponding CALL CS has not previously been 
executed thus the Mxxx member does not exist. Upon the first execution of a particular 
CALL CS, the Secondary Edit Phase (XCA) is invoked to validate the specified Secondary 
Input Stream and to construct a corresponding Secondary CS Set residing on XSUNIT as the 
Mxxx member previously assigned. The Mxxx member has the same format as the root member, 
M001, and it contains the set of control statements which compose the Secondary Input 
Stream in executable form. The last CS record in the Mxxx member is a RETURN CS simulated 
during the Secondary Edit Phase to allow eventual return of control to M001. Upon comple- 
tion of the Secondary Edit Phase, the M001 member is put in suspended execution by trans- 
f erring execution control to the new Mxxx member. 

Upon a subsequent execution of a particular CALL CS, the specified Secondary Input 
Stream does exist in executable form as the Mxxx member previously constructed during the 
Secondary Edit Phase. Thus, the Secondary Edit Phase is not invoked and the M001 member 
is put in suspended execution immediately by transferring execution control to the corre- 

sponding Mxxx member. 

When execution control is transferred to a Secondary CS Set, execution begins with 
the first CS record and continues sequentially, until the final CS , the RETURN, is en- 
countered. The sequential flow may be altered, as in the Primary CS Set. Execution of 
the RETURN indicates the Secondary CS Set has been completed and control is transferred 
back to the Primary CS Set. Execution resumes with the CS immediately following the CALL 
CS which suspended execution by the Primary CS Set. 

During execution of a Secondary CS Set, a CALL CS may also be encountered. The 
currently executing Secondary CS Set is put in suspended execution, the Secondary Edit 
Phase is invoked upon the first execution of the particular CALL and execution control is 
transferred to the specified Mxxx member, or Secondary CS Set. The process invoked by 
encountering a CALL CS in a Secondary CS Set is identical to the process invoked by 
encountering a CALL CS in the Primary CS Set. 
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There is no limit to the number of Mxxx members which may be in suspended execution. 
Upon completion of the "called" Secondary CS Set, the "calling" CS Set is brought back 
into current execution and execution resumes with the CS immediately following the CALL CS 
which invoked the suspended execution. Eventually as the suspended Secondary CS Sets are 
one by one brought back into current execution and completed, the Primary CS Set is 
brought back into current execution. The last CS record in the Primary CS Set is the 
ENDCS which when executed invokes the Normal Termination Phase. The Normal Termination 
Phase terminates ANOPP with no return to XCSP. Thus, ANOPP is terminated by invoking the 
Normal Termination Phase upon execution of the ENDCS during the CS Processing Phase. 

The CS Processing Phase is temporarily interrupted by two conditions. The first is 
the request for a Functional Module (F.M.) to be executed via the EXECUTE CS. The second 
is a non-fatal error occurrence while processing a CS record. 

The EXECUTE CS is processed by XCSP as follows. The Alternate Names Table (ANT) is 
constructed according to the alternate name specifications on the EXECUTE CS. The F.M. 
and ANOPP executive modules will utilize the ANT during the F.M. Processing Phase which 
follows XCSP interruption and return to the driver XM. A set of alternate names defined 
by the ANT is valid only during the F.M. Processing Phase. All entries in the ANT are 
deleted upon completion of that Phase. Thus, the ANT always has zero entries upon entry 
to XCSP. The name of the F.M. to be executed has been pre-processed during the Primary or 
Secondary Edit Phase; and the EXECUTE CS record upon execution contains an integer which 
corresponds to the F.M. name specified on the CS card image in the Primary or Secondary 
Input Stream. The correspondence between a particular integer and a particular F.M. is 
unique and was assigned when the F.M. was installed into ANOPP. This integer which is 
sufficient for the F.M. Processing Phase to determine, load, and execute the proper F.M. 
is placed in the XCSP output variable REQ (/XCS/ common block). 

If a non-fatal error occurs during the processing of any CS, the ANOPP error 
indicator NERR is set to a .TRUE, value. Whether or not that CS processing was completed 
or partially completed depends on the particular CS. 
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Upon XCSP interruption and return to the driver XM, the existing environment is 
defined sufficiently to allow for resuming the CS Processing Phase by a subsequent entry 
to XCSP. All data members utilized are closed. 

All CS records are processed by the XCSP modules according to individual require- 
ments. The card images of the CS are printed as the CS is executed depending on the 
system parameter JECH0 value. 

Logical Description : In the following logical description of XCSP, there is no 

attempt to discriminate between the initial entry or a subsequent entry to XCSP. Although 
the initial entry to XCSP always begins processing with the first CS record m M001 and a 
subsequent entry resumes processing with a CS record in any Mxxx member, there is no 
logical differentiation required internal to the XCSP module. The first entry to XCSP is 
logically identical to any subsequent array. The environment which is defined by the 
input to XCSP dictates either the beginning of CS processing or a resumption of CS pro- 
cessing and both environments are processed identically. 

On entry, XCSP calls the XCSPM module to initialize the environment to resume pro- 
cessing with the next CS record in the currently executing Mxxx member. Local Dynamic 
Storage (LDS) is initialized. The Mxxx member, defined by MEMCUR , with which execution is 
to begin is opened to read. In the MDBT , the MDB corresponding to Mxxx contains the 
length of the largest CS record at MRL position and the length of the label record at MLL 
position. This information is used to allocate in LDS a block large enough for any CS 
record on Mxxx and a block sufficiently large for the label record. The label record on 
Mxxx is then read into the LDS label block to define all valid label names and the corre- 
sponding CS records for this Mxxx member. The MCUR entry of the MDB contains the posi- 
tion of the last CS record executed. The Mxxx member is positioned so that the next 
record read will be the CS record with which execution is to resume. 

Upon return from the XCSPM module, XCSP enters an indefinite iteration of processing 
the next CS in the current Mxxx member. The current record pointer is incremented by one 
to define the position of the CS record to be executed. Mxxx is positioned to the CS 
record to be executed and it is read into the CS record block in LDS. The card image of 

Ok;: ; 
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this CS is then printed if the system parameter JECH0 is set accordingly. The name of the 
CS is identified and the appropriate module is called to process the CS. A list of the 
valid CS names for processing by XCSP along with the name of the module called by XCSP to 
execute the CS is given in Table 3. 

All the modules which process a CS have the same input available and must satisfy the 
same output requirements with respect to XCSP interface. The input uniformly required is 
the CS record which fully defines the act to be performed. Additional input is specific 
to the particular CS. The output environment which must be provided upon return to XCSP 
must allow XCSP to continue its iterative processing. Specifically, the output must 
include the following: 


1. MEMCUR defines the currently executing Mxxx member. 

2. The ^ MCUR entry in the MDB corresponding to the current Mxxx must contain the 
position of the next CS record to be executed minus 1. In most cases where 
the sequential flow is unaltered, the value will be unchanged from the input 
value and will reference the CS record just executed. In other cases where 
a control statement alters the sequential flow, the value must be reset such 
that ^ it points to the CS immediately before the next CS to be executed. This 
setting always allows XCSP to increment the current record position by 1 in 
continuing the iterative loop or upon a subsequent entry of XCSP when the 
iterative loop is again begun. 

3. The label block in LDS contains the label record of the current Mxxx. 

4. The CS record block in LDS must be large enough for any CS record on the 
current Mxxx. Usually the CS record for the CS just completed has remained 
unaltered in the block but this is not required. The size of the LDS block, but 
not necessarily the contents, must be insured. 

5. Mxxx is opened to read and is positioned such that the next record read will 
correspond to the next CS to be processed. 

6. The current Mxxx member is the only member open for any reason. 

Most of the CS processing modules perform functions which are independent of XCSP 
interface requirements. The basic input to these modules is the CS record which fully 
defines the action to be performed. Other input for particular CS processing modules may 
be required but is not relevant to nor dependent upon XCSP interfaces. Upon entry to 
these modules the XCSP output requirements are automatically satisfied and remain un- 
altered upon return to XCSP . No change has occurred to alter the sequential execution 
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Control 


Table 3. 


Statement Name 
ARCHIVE 
ATTACH 
CALL 

C0NTINUE 

CREATE 

DETACH 

DR0P 

ENDCS 

EXECUTE 

G0T0 

IF 

L0AD 

PARAM 

PR0CEED 

PURGE 

RETURN 

SETSYS 

TABLE 

UNL0AD 

UPDATE 


ANOPP Executing Module 
XAR 
XAT 
XCA 
XC0 
XCT 
XDT 
XDR 
XEN 
XEX 
XG0 
XIF 
XLD 
XPA 
XPR 
XPU 
XRE 
XSS 
XTB 
XUN 
XUP 


Valid ANOPP Control Statement Names Processed by XCSP. 


3.5-45 


EXECUTIVE MODULES 


thus CS processing always continues with the CS record immediately following the CS just 
completed. The modules not of this type are those which process the CALL, ENDCS, EXECUTE, 
G0T0, IF, and RETURN control statements. 

Processing of the EXECUTE CS by the XEX module does affect XCSP execution and has 
additional output requirements. The required output environment is also present on entry 
to XEX as in the majority of CS processing modules. The XEX module additionally provides 
upon return to XCSP the integer corresponding to the F.M. to be executed via the common 
block /XCS/ variable REQ. XEX also builds the ANT in GDS to include alternate names 
specified on the EXECUTE CS. Upon entry to XEX, the ANT always has zero allocated entries 
and upon exit the ANT has the exact number of alternate names specified on the EXECUTE CS 
which is zero or greater. Upon return to XCSP, a local variable is set to indicate that 
XCSP iterative processing is to be interrupted due to a F.M. execution request. 

The G0T0 CS and the IF CS usually change the execution sequence upon return to XCSP 
and thus the modules XG0 and XIF must insure the output requirements for XCSP interface 
are satisfied. The G0T0 CS will always transfer execution control to a CS record in the 
current Mxxx member whereas the IF CS will do so conditionally. The CS to which transfer 
is made is usually not but may be the CS immediately following the G0T0 or IF statement. 
Input to XG0 and XIF include the CS record and the label record. The position of the next 
CS to be executed is determined from the label record. The Mxxx member is positioned to 
this CS record and MCUR is set to that position minus 1. Other output requirements are 
satisfied upon entry with no need for alteration. 

The ENDCS indicates the normal completion of the Primary CS Set and upon execution 
the normal termination phase is invoked. The XEN module closes M001 and terminates ANOPP 
without return to XCSP. Thus XEN has no output requirements. 

The CALL CS requests that the current Mxxx member be suspended and a specified 
Secondary Input Stream be executed; thus, the processing modu 1 e XCA must insure the 
output requirements upon return to XCSP are satisfied. Upon entry to XCA, the name of the 
Mxxx to be executed is contained in the CALL CS record. The MDB entry in the MDBT corre- 
sponding to this Mxxx is interrogated to determine if this CALL has been executed previously 
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and the executable form of the Secondary Input Stream has been constructed and is avail- 
able for usage or if this CALL has not been executed previously and the executable form is 
not available on Mxxx for usage. If either MRL or MLL entries in the MDB are zero, then 
Mxxx has not yet been constructed; if either is non- zero then Mxxx has been constructed. 

If construction has not yet occurred, then XCA invokes the Secondary Edit Phase to vali- 
date the Secondary Input Stream and construct the executable form, or Secondary CS Set, as 
the Mxxx member on XSUNIT. See Section 3. 5.4.6 for a full description of the Secondary 
Edit Phase. If construction has previously occurred, then the Secondary Edit Phase is by- 

passed. 

XCA calls the module XCATRA to transfer execution to the Mxxx member containing the 
requested Secondary CS Set. The current Mxxx member is closed and the LDS blocks for the 
CS record and label record are freed. MEMCUR is set to the new Mxxx member to be exe- 
cuted. MCUR in the MDB corresponding to the new Mxxx member is set to zero (0) indicating 
the next CS to be executed is CS record number one (1). XCATRA then calls XCSPM to perform 
initialization functions identical to those performed upon entry to XCSP. XCSPM opens 
MEMCUR to read, allocates an LDS block sufficient for the largest CS record on MEMCUR, 
allocates an LDS block for the MEMCUR label record and reads the label record into the 
block, and positions MEMCUR to the next CS record to be executed which is the first CS 
record. Upon completion of the XCATRA module the currently executing Mxxx member upon, 
entry to XCSP has been suspended and the specified Mxxx has been brought into current 
execution. The output requirements for return to XCSP are satisfied. 

Upon execution of a RETURN CS the module XRE is called by XCSP to reverse the process 
performed by XCA and return control to the "calling" or suspended Mxxx. The "called" 
member (MEMCUR upon entry to XRE) is closed, the LDS blocks are freed and LDS is released. 
The name of the "calling" Mxxx member, defined by the name in the MCALL entry in the MDB 
of the "called" Mxxx, is retrieved and placed in MEMCUR, thus, bringing back into exe- 
cution the suspended Mxxx. The module XCSPM is then called to complete the output require- 
ments. XCSPM opens MEMCUR to read, allocates an LDS block sufficient for the largest 
CS record on MEMCUR, allocates an LDS block for the label record of MEMCUR and reads the 
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label record into the block, and positions MEMCUR to the CS record following the CALL 
which invoked the suspension. Upon completion of XCSPM the return of control is complete 
and the output requirements for XRE return to XCSP are satisfied. 

When the current CS has been completely processed by the appropriate module and 
return is made to XCSP, the iterative processing continues by processing the next CS. The 
iterative processing of CS records continues either until the ENDCS is executed to termin- 
ate ANOPP normally or until one of two conditions is encountered. The first condition is 
the occurrence of a non- fatal error within a CS processing module. Upon return from a CS 
processing module within which an error occurred, the ANOPP logical error indicator, NERR, 
is set to .TRUE.; if no error occurred it is .FALSE. . The second condition is the 
execution of an EXECUTE CS. Upon return from the XEX module, XCSP sets the local variable 
ISTAT to 1 (one) indicating a F.M. execution request. If either NERR or ISTAT is set to 
.TRUE, or 1 (one) respectively, then the iterative CS processing is interrupted and XCSP 
prepares for return to XM. The LDS blocks are freed and the current Mxxx (MEMCUR) is 
closed. XCSP then returns to XM. 

Error Philosophy ; There are two types of errors which may occur within XCSP pro- 
cessing, fatal and non-fatal errors. 

A fatal error is the detection of a condition which inhibits further XCSP processing. 
Fatal errors include: a) conditions which should not exist logically within ANOPP, such 

as the XSUNIT does not exist when an attempt to open an Mxxx member is performed, and b) 
conditions which prevent further processing to be productive, such as insufficient LDS for 
required XCSP block allocations. Fatal errors may occur within any module called by XCSP 
and ANOPP and are abnormally terminated immediately. Most XCSP called modules abort via 
the EM auxiliary module XXFMSG which invokes the Error Termination Phase (see Section 
3. 5.4.8 for full description). However, the modules which process the Data Base Manage- 
ment control statements generally utilize the MMERR and TMERR auxiliary modules. Fatal 
Member Manager errors occurring during processing of Member Manager control statements 
(ARCHIVE, ATTACH, CREATE, DETACH, DR0P, L0AD , PURGE, and UNL0AD ) abort via MMERR. Fatal 
errors occurring during processing of Table Manager control statements abort via TMERR. 
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A non-fatal error is the detection of an abnormal condition during CS processing 
which does not inhibit further productive XCSP processing. Generally, these are user 
errors resulting from invalid Primary or Secondary Input Streams such as a non existent 
unit or member specified as a Table Input Stream. The CS processing module detecting the 
error prints an informative message via the EM auxiliary XXNMSG, the MM auxiliary MMERR, 
the TM auxiliary TMERR, and the auxiliaries XLDERR and XUNERR. NERR is set to .TRUE, 
before returning to XCSP. Before attempting to continue CS processing, XCSP will detect 
the NERR setting and return to the driver XM for error processing. 


EXECUTIVE MODULES 


3. 5.4.4 Functional Module Processing Phase (XFM) 


Purpose : The XFM module controls the Functional Module (F.M.) Processing Phase. The 

F.M. specified on the EXECUTE CS which interrupted the CS Processing Phase is brought into 
execution. Upon completion of the F.M. the integrity of the ANOPP system environment is 
validated and insured before return to the driver XM. 

Input : 

1. Data Base Structures 

All data members are closed. 


2. Common Block Variables 


/xcs/ 

REQ 


NXLEV1 

NFM 


the integer corresponding to the F.M. to be executed. The corre- 
spondence is determined when a F.M. is installed into ANOPP. For 
each valid F.M. name which may appear on ah EXECUTE CS there is a 
unique integer in the range (NXLEV1+1) through (NXLEV1+NFM) inclusive. 
The integer corresponding to the requested F.M. was placed in REQ 
during the CS Processing Phase when the EXECUTE was encountered. 

the number of executive modules which are called directly by XM and 
are loaded at segmentation level 1. These include XBS, XRT, XCSP, 
and XMERR . The F.M. integer assignments begin with NXLEV1+1. 

number of F.M. installed. This includes the F.M. names which are 
available for F.M. testing before permanent installation. These 
names are FM1, FM2 , FM3, FM4, FM5. 


/XCSFM/ 

LANT - the IDX of the Alternate Names Table in GDS. 


3. Control Structures 

ANT - the Alternate Names Table resides in GDS and is a System Table Type 
1 which contains an entry for each alternate name specified on the 
EXECUTE CS, 

Output : 

1. Data Base Structures 

All data members are closed. 

2. Common Block Variables 
/XCS/ 

REQ - the value is zero indicating the F.M. Processing Phase is complete. 
/XCVT/ 

NERR - the ANOPP logical error indicator is set to .TRUE, if an error oc- 
curred within the F.M. or during the post F.M. "cleanup” procedures 
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which insured the system integrity. If no error occurred, NERR is 
.FALSE. . 

3 . Control Structures 

ANT - the Alternate Names Table in GDS contains no entries. It is 
initialized to zero allocated and zero current entries. 

Functional Description : The F.M. which corresponds to the integer REQ is loaded and 

brought into execution. Upon completion of the F.M. the integrity of the ANOPP system 
environment is validated and insured. 

The functions required to validate and insure the integrity of the ANOPP system 
environment upon completion of a F.M. are called cleanup procedures. Cleanup procedures 
validate conditions and perform corrective action if the condition is unsatisfied. The 
conditions validated and the corrective action taken are described below: 

1. Condition: LDS has been released 

Corrective Action if condition unsatisfied : LDS is released 

2. Condition: All user consolidation locks on LDS and GDS (excluding the master 

lock on GDS) are released. 

Corrective action if condition unsatisfied : release user locks. 

3. Condition: All data members are closed. 

Corrective action if condition unsatisfied : logically close any data member 

which is operT. A logical close of a member is performed by deleting the member 
from all MM tables indicating activity on the member. If the member was open 
to write (direct or scratch) the newly written complete or partial member is 
lost as if the write had never occurred. 

4. Condition: all data tables are closed. _ _ 

Corrective action if c ondition unsatisfied : any opened data table will be 

logically closed and released from core residence. If the table was opened 

to alter, the altered table is not written to the member as in a normal close; 
thus, the altered table is lost for subsequent retrieval. 

If any of the conditions is unsatisfied, thus resulting in corrective action, the 
F.M. Processing Phase is considered to be in error and NERR is set to .TRUE. . 

The alternate names defined on the corresponding EXECUTE CS are valid only during 
execution of a F.M., thus the ANT is initialized to zero allocated entries and zero 
current entries to indicate a null set of names. 

Upon completion of the cleanup procedures and ANT initialization, the F.M. Processing 
Phase is terminated and return is made to the driver XM. 
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Logical Description : Upon entry to XFM, REQ is validated to insure the integer 

corresponds to a F .M ♦ instated in the ANOPP system. REQ must satisfy the following 
conditions : 

NXLEV1 < REQ < NXLEV1 + NFM 

The module XLINK is then called to load and execute the corresponding F.M. 

XLINK contains the one-to-one correspondence of integers and F.M. names and calls the 
appropriate F.M.. Upon completion of the F.M., the XLINK modules returns to XFM. 

XFM continues by performing the cleanup procedures via calls to the modules XFMDSM, 
XFMMM, and XFMTK . 

XFMDSM validates that LDS has been released and that all user consolidation locks on 
LDS and GDS have been released. If necessary LDS is released, all user locks on LDS and 
GDS are released, and the indicator NERR is set to .TRUE. . 

XFMMM validates that all data members are closed. If a data member is found to be in 
an open state then the member is removed from the MM tables AMD, MCB and NERR is set to 
.TRUE. . If the member had been opened to write (direct or scratch) the member is closed 
as if the open had never occurred; thus, the newly written member is unavailable on a 
subsequent open. 

XFMTM validates that all data tables are closed. If a data table is found to be in 
an open state, it is removed from GDS core residence and NERR is set to .TRUE.. If the 
table had been opened for alteration, the table is closed as if it had never been opened; 
thus, the altered table is not written to the data unit for subsequent retrieval. 

Upon completion of the cleanup procedures the module XFMANT is called to zero the 
ANT. The GDS block containing the ANT is freed and a new GDS block allocated for zero 
entries in the ANT is requested. The ANT is intialized to zero allocated and zero current 
entries. 

XFM is completed and returns to XLINK thereby returning to the driver XM. 
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Error Philosophy : If an error has occurred during execution of a F.M., then the 

ANOPP error indicator NERR has been set to .TRUE, before return fro™ the F.K. to XFM via 

XL INK. 

Regardless of the error return status from the F.M., the cleanup procedures are 
executed and if a corrective action is required NERR is set to .TRUE. . 

Upon return from XFM to XM if NERR is set to .TRUE, then XM determines action to be 
taken. 


ORIGINAL- PAGE IS 
OF POOR QUALITY! 
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3. 5.4. 5 Error Processing Phase (XMERR) 


P - Urp0Se : The module XMERR controls the Error Processing Phase. A non-fatal error 

was encountered during processing of a control statement in either the CS Processing Phase 
Processing Phase. Depending on the value of the system parameter JC0N, either 
1) the CS sequence is searched sequentially forward for either a PR0CEED CS or the ENDCS 
CS whichever is encountered first; or 2) no action is taken allowing the CS Processing 
Phase to resume with the next CS following the CS in error. 


Input : 

1. Data Base Structures 


2 . 


XSUNIT 


the unit XSUNIT contains all Mxxx members constructed by the 
Primary and Secondary Edit Phases. All Mxxx members are closed. 


Common Block Variables 
/XCS/ 

MEMCUR - name of the Mxxx member on XSUNIT in current execution. 

MXMDB - IDX of the Member Description Block Table (MDBT) residing in CDS 

MNAME , MCUR, MCALL MRE, MLL - position parameters for a Member Description 
Block (MDB) which is an entry in the MDBT. 

/XSPT/ 

JC0N " XMFRR° S1 ^ 1 TrmM tem ?^ ameter indicatin g ^e action to be taken by 
FATcr IE JC0N ~ -TRUE., then no action is taken. If JC0N = 

rmnc the CS sec l uence is searched for a PR0CEED CS or the 

LNDCS whichever occurs first. 


Control Structures 

MDBT - the Member Description Block Table (MDBT) residing in CDS 

1 C an MTYB .c i 


» - V ‘ ^ ^ l / 1 COlUlil] 

is an MDB, or entry, for each Mxxx name assigned, 
descriptive and status information about the Mxxx. 


There 
The MDB contains 


Output : 


Data Base Structures 

XSUNIT - all Mxxx members remain unchanged and are closed. 

Common Block Variables 

MEMCUR - the name of the Mxxx in current execution resulting from action 

If™* by XME ^ R * *1 a search was performed then Mxxx contains the 
first encountered PR0CEED or the ENDCS. If a search was not per- 
formed then MEMCUR is unchanged from the input value. 
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3. Control Structures 

MDBT - if a search was not performed then all MDB entries are unchanged. 

If a search was performed, then the value of the contents of the 
MCUR position in the MDB of each Mxxx member involved in the 
search process has changed. This value in the MDB corresponding 
to MEMCUR is the position of the CS record which _ immediately pre- 
ceeds the found PR0CEED or ENDCS CS record. (This is necessary 
for the CS Processing Phase to resume with the PRjZCEED.or EhDC .) 

This value in the MDB corresponding to any other Mxxx involved 
in the search is the position of the last CS record in Mxxx which 
is now in completed execution. 

Functional Description : The Error Processing Phase determines the action to be taken 

whenever a non-fatal error occurs during the processing of a CS. The error could have 
been encountered during the CS Processing Phase or during the F.M. Processing Phase. If 
it occurred in the former phase, then the CS was directly responsible for the error. If 
it occurred in the latter phase, which is always the result of an EXECUTE CS being pro- 
cessed, then the error was not directly caused by the EXECUTE CS but instead by the F.M. 
which was executed. In both cases, however, the CS last processed by the CS Processing 
Phase is considered by XMERR to be in error and the CS image is printed with 

message . 

Further action to bo taken is determined by the system parameter JC«N. If JCW « 
set to .TRUE, on entry, then no further action is taken. Subsequently, when the CS 
Processing Phase is resumed by the driver », processing win continue with the CS im- , 
mediately following the CS in error. If «>» is set to .FALSE, on entry, then a search is 
performed to locate either the first PROCEED CS after the CS in error or if no PROCEED 
is found, then the ENDCS CS. Subsequently, when the CS Processing Phase is resumed by the 
driver XH, processing will resume with the PROCEED or ENDCS. 

The search for the PROCEED begins with the CS following the CS in error. The search 
continues sequentially forward through th. current CS set in execution. If during the 
search a CALL CS is encountered, it is not processed and th. Secondary CS Stream specified 
is not brought into the search process. The CALL CS is skipped as any other CS. If the 
current CS Set ia a Secondary CS Set and it ia exhausted without a PROCEED CS, then upon 
encountering the RETURN CS, the Mxxx containing the Secondary CS Set is closed and pro- 
cessing returns to the CS immediately following the CALL CS in th. calling metier. This 
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procedure continues until a PR0CEED CS is detected or until processing returns to the 
Primary CS Set and an ENDCS CS is detected. On exit from XMERR, all Mxxx members used in 
the search are closed. 

Logical Description : Immediately upon entry XMERR calls the XCSPM module to open the 

currently executing Mxxx member, allocate local core to receive a control statement 
record from the Mxxx member, and position the Mxxx member to the next CS record. 

Upon return from XCSPM, the Mxxx member is positioned to the CS in error via the 
MMSKIP service module. The CS in error is gotten from the current Mxxx via the MMGETR 
service module. The CS record is echoed with an appropriate message telling the user that 
the current CS resulted in a system error and execution will continue with the next CS 
record or with the next PR0CEED CS, depending on the system parameter JC0N. 

If the system parameter JC0N is set to .TRUE., indicating that execution should 
continue with the CS record following the CS in error, then the system parameter MEMCUR is 
unchanged and the number of the CS record in current execution on MEMCUR (the CS in 
error) is also unchanged. This insures that the CS record to be executed next by the 
Control Statement Processing Phase (XCSP) will be the CS immediately following the CS in 
error . 

If the system parameter JC0N is set to .FALSE., this indicates that execution should 
not continue with the CS following the CS in error, but instead should continue with the 
next PR0CEED CS. If a PR0CEED CS is not detected, then execution should continue with the 
ENDCS CS. 

In the case that JC0N is .FALSE., XMERR sequentially reads CS records from MEMCUR, 
bringing each into Local Dynamic Storage via MMGETR, until a PR0CEED or ENDCS CS is de- 
tected. In the event that a RETURN CS is detected, the current Mxxx is closed, system 
parameter MEMCUR is defined as the calling Mxxx, the calling Mxxx is opened, and the 
search continues in the calling member. Detection of a CALL CS in the current CS Set does 
not alter the course of the search. The CALL CS is skipped and the search continues with 
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the CS immediately following the CALL. This procedure is iterated, and the number of the 
CS record in current execution on MEMCUR is incremented, until a PR0CEED or ENDCS CS is 
detected . 

Or. exit from XMERR, the name of the current Mxxx member is defined by the system 
parameter MEMCUR, and the number of the CS record in current execution for the MEMCUR Mxxx 
has been defined dependent on the value of the system parameter JC0N. 

Error Philosophy : The XMERR module aborts only if an error is detected by MMGETR 

while trying to get the next CS record from the current Mxxx member. 




■ rx'i 
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3. 5.4.6 Secondary Edit Phase (XCA) 


Purpose : The Secondary Edit Phase module (XCA) is called by the Control Statement 

Processing Phase (XCSP) to process a CALL control statement. If this is the first execu- 
tion of the CALL CS, XCA builds an Mxxx member containing CS records that correspond to 
the control statements in the Secondary Input Stream. If the Mxxx member is built success- 
fully, or if the Mxxx has been previously executed, the Secondary Edit Phase provides the 
environment required for the CS Processing Phase to resume execution with the first con- 
trol statement on the new Mxxx member. 

Input : Primary Input to the Secondary Edit Phase is the Secondary Input Stream 

residing in card image (Cl) format on the member specified as DU(DM) on the CALL CS. 
Pertinent input is described below. Other input required for processing but not necessary 
for understanding, is not included. 


1. Data Base Structures 

DU(DM) - the data member specified by the DU(DM) on the CALL CS contains 
the Secondary Input Stream in Cl format. 

2. Common Block Variables 

/XCS/ 

MEMCUR - the name of the Mxxx member in current execution on entry to XCA 
is defined by MEMCUR. MEMCUR names the Mxxx member where the 
CALL CS resides. 

/XCVT/ 

NERR - the executive system logical error indicator NERR is always .FALSE. 

on entry to XCA, indicating that no errors have been detected in 
processing . 

3. Control Structures 

MDBT - the Member Description Block Table resides in CDS and is a system 
table type 1. The MDB entry for the Mxxx member being called into 
execution exists in the MDBT in initialized or executable format. 
The values in an initialized MDB indicate that the Mxxx does not 
exist, whereas the values in an executable MDB indicate that the 
Mxxx has been constructed. 

Output : 

1, Data Base Structures 

Mxxx - the first time a CrLL CS is executed, the Secondary Edit Phase 

validates and builds the Mxxx member being called into execution. 
Mxxx contains a variable length control statement record for each 
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complete CS edited in the Secondary Input Stream and a Label Record 
that provides a cross-reference to each labeled CS on Mxxx. The 
member is in a format recognized by the CS Processing Phase. If 
an error is detected in the Secondary Input Stream , writing to the 
Mxxx member is suppressed but editing continues until the Secondary 
Input Stream has been exhausted. 


2. Common Block Variables 
/XCS/ 

MEMCUR - the name of the current Mxxx type member in execution. If the 

CALL CS has been processed without error, MEMCUR indicates the Mxxx 
to which control has been transferred and the Mxxx in execution on 
entry has been closed. But if errors have been detected m process- 
ing the CALL CS, MEMCUR is unchanged from its entry value. 


/XCVT/ 

NERR 


the executive system logical error indicator. If an error is de 
tected in processing the CALL CS, NERR is set to .TRUE, on exit. 


3. 


Control 

MDBT 


Structures 

- the first time a CALL CS is executed and an Mxxx member is built, 
a Member Description Block entry (MDB) is put into executable format 
for the Mxxx built. 


Functional Description : The XCA module performs all operations necessary to process 

a Secondary Input Stream as a result of a CALL CS. If it is the first execution of the 
CALL CS, then an Mxxx type member must be built from the card images in the Secondary 
Input Stream. The Secondary Input Stream resides on the member specified by the DU ( DM ) 
field on the CALL CS image. The name of the Mxxx member to be built is found in the CALL 

CS record. 

The Mxxx member is built in a single sequential pass on the Secondary Input Stream. 
As each CS in the Secondary Input Stream is processed, substitutions are made in the CS 
image from optional replacement names specified on the CALL CS. 

Once substitutions have been made, the new CS image is used to build an unformatted, 
variable length CS record. CS records for the Secondary CS Set are edited and built m 
the same manner used to build CS records for the Primary CS Set. 

Certain CS names, or forms of a CS, that were valid in the Primary Input Stream are 
not valid in the Secondary Input Stream. The S0URCE=* form of the UPDATE and TABLE 
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control statements are not valid to the Secondary CS Set. Neither is the DATA CS valid to 
the Secondary CS Set. 

A CALL CS is processed the same in the Primary Input Stream and the Secondary Input 
Stream. An Mxxx member name is assigned and an MDB entry initialized each time a CALL CS 
is encountered. 

If an end-of-member condition is detected, a RETURN CS is simulated for internal 
control. Detection of the RETURN CS indicates the end of the Secondary Input Stream. 

As the Mxxx member is built, the MDB for the Mxxx is put into executable format. 

If the Mxxx member is built successfully, or if the Mxxx was built and executed 
previously (due to a previous processing of the CALL CS), then XCA transfers control to 
the new Mxxx so that the CS Processing Phase (XCSP) will resume execution with the first 
CS record on the new Mxxx. In order to provide such an environment, the following steps 
must be done: 

1. Close the Mxxx member that was in execution on entry to XCA. 

2. Open the new Mxxx to read and position to the first CS record on the member. 

3. Free LDS blocks for the Mxxx member that has been closed and re-allocate LDS 
blocks as required for processing the new Mxxx member. 

4. The MEM CUR parameter that defines Mxxx member in current execution is set to 
name of new Mxxx. 

If the Mxxx member was not built successfully, then the entry environment is un- 
changed. Control is not transferred to the new Mxxx. Before exit, an error indicator is 
set to inform the caller that an error was detected in the Secondary Edit Phase. 

Logical Description : Immediately upon entry to the XCA module, the XCAI module is 

called to open the member containing the Secondary Input Stream and the Mxxx member to be 
built. In addition, XCAI allocates expandable LDS blocks necessary for building the Mxxx 
Label Reference Table (LRT) and Label Record Table (LREC) , and fixed length LDS blocks for 
building the Substitution Table (LSUB) and the new CS Image Block (NCSIB). 
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The XCA module then calls XCABST to build the Substitution Table from the replacement 
values, if present, specified on the CALL CS. If at least one replacement set is speci- 
fied on the CALL CS, XCABST cracks the CALL CS image without converting fields (XCRWC). 
Replacement sets appear in the form oldvalue = newvalue on the CALL CS. To build the 
Substitution Table, the = fields are stripped out and only the old- and newvalue fields 
are retained. Upon completion, the Substitution Table contains the type code and corre- 
sponding oldvalue field and the type code and corresponding newvalue field for each 
replacement set. 

Once the Substitution Table is complete, the following process is iterated until the 
Secondary Input Stream has been exhausted (a RETURN CS detected or simulated): 

The XCANCS module is called to produce a new CS image by getting the next CS 
image from the Secondary Input Stream and making field substitutions as required by 
the CALL CS. Field substitutions are made according to values in the Substitution 
Table previously built on entry to XCA. Any field type may be replaced by any other 
field type. The comment portion of the original CS, if present, is retained. If 
the new CS image with substitution causes the comment portion to overflow a card 
image, then the comment portion is truncated accordingly. If the CS image without 
comment exceeds the maximum allowable card images, then an end-of-data character is 
simulated and the CS is truncated. 

If an end- of -member condition is detected before a RETURN CS is detected, a 
RETURN CS is simulated for internal control. If an end-of-member condition is 
detected on an incomplete CS, then that CS is replaced by a RETURN CS. 

If the current CS is found to be in error the system parameter JECH0 is 
automatically turned on so that subsequent images will be echoed. A CS is considered 
in error if the original CS image exceeds maximum allowable images or if the new 
CS image without comment portion exceeds maximum allowable images. 

When the new CS image is complete, the XCAMXX module is called to build and 
validate a control statement record valid for a Secondary CS Set. The CS record in 
built in the same manner used to build control statement records for the M001 root 
member. XRT sub-modules are called to perform the following functions: 

1. Update label record table for Mxxx being built (XRTBLR) 

2. Update label reference table for Mxxx being built (XRTLRF) 
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3. Perform syntax check according to format requirements for particular 
CS (XRTSYN) 

4. Simulate CS complete condition if CS image exceeds maximum cards per 
CS with no valid CS terminator (XRTTC ) 

5. Get CS record into format ready to be written on new Mxxx (XRTBCS) 

Comment cards (CS where first non-blank character is end-of-data character) are 
included on the new Mxxx as a CS with C0NTINUE substituted as the CS name. 

The XCAMXX module allocates and initializes an MDB entry in the MDBT for each 
CALL CS processed. The XRT sub-module XRTCAL, is called to form the new Mxxx name 
assigned to the CALL CS and initialize the MDB. 

If a CS error is detected, the Mxxx member is considered to be in error. NERR 
is set to .TRUE, and writing to the Mxxx member is inhibited, although editing and 
building CS records continues. A CS is considered in error under any of the following 
circumstances : 

1. Unrecognizable field detected on CS image 

2. Invalid label field (either invalid form or duplicate labels) 

3. Invalid CS name 

4. Invalid syntax check for CS name 

5. Maximum images (MAXCC) exceeded 

Once the Mxxx member has been built , the XRT sub-module XRTLSA is called to insure 
that all label references on the member are satisfied. If all labels have been satisfied 
and the Mxxx member is error free, then the label record is written on the Mxxx member as 
the last record. 

The XCACL0 module is then called to perform the closing functions, XCACL0 frees the 
Substitution Table (LSUB), the New CS Image Block (NCSIB), the Label Record Block (LREC), 
and the Label Reference Table (LRT) in Local Dynamic Storage. XCACL0 also closes the 
Secondary Input Stream member and the new Mxxx member just built. 

XCA then completes the MDB entry in the MDBT for the new Mxxx member by inserting in 
the MDB the name of the Mxxx that called the new Mxxx member just built. The calling 
member is the Mxxx member that was in current execution on entry to XCA. 

If the new Mxxx member was successfully built, or if the Mxxx member was previously 
executed then the XCATRA module is called to transfer execution control to the new Mxxx. 
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XCATRA first closes the Mxxx member that was in current execution on entry to XCA. 

Then Local Dynamic Storage blocks are freed and re-allocated according to the requirements 
for the new Mxxx. The new Mxxx is opened to read and the label record is validated and 
moved to the newly allocated LDS Label Record Table. Then the new Mxxx is positioned to 
read the first CS record. 

If no errors have been detected on exit from XCA, then XCATRA has set up the appro- 
priate environment such that XCSP will resume execution with the first CS record on the 

new Mxxx member. 

Error Philosophy : The Secondary Edit Phase aborts via the XXFMSG fatal message 

writer if an error is detected when opening the new Mxxx member to be written. 

The Substitution Table is allocated for exact requirements of replacement values 
specified on the CALL CS. An error is indicated (possibly in the replacement fields 
specified on the CALL CS) if the number of words moved to the table m building does not 
match allocated table length. In such a case, XCABST aborts via XXFMSG fatal message 

writer . 

When building a CS record for the new Mxxx member, XCAMXX aborts via XXFMSG if the CS 
record block overflows because the allocated length was not the maximum required or if an 
unexpected Member Manager return status is detected while reading the Secondary Input 

Stream Member. 

Several other errors are not immediately fatal but do result in ultimate termination 
of processing at the end of the Secondary Edit Phase. If the Secondary Input Stream 
member does not exist or is not in card image (Cl) format, logical error indicator NERR is 
set and a message is printed. Also, the error indicator is set and message printed if LDS 
is insufficient to allocate all of the tables required for processing. 

Edit errors detected in the Secondary Edit Phase cause writing on the new Mxxx member 
to be suspended. However, editing and building CS records continues until the Secondary 
Input Stream has been completely processed. Error messages are printed before the corre- 
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sponding CS record is echoed. If a CS error is detected, the system parameters NERR and 
JECH0 are set to .TRUE, and the current CS is echoed. 

A CS image that exceeds the maximum card images (MAXCC) per CS falls under the 
category of edit errors above. The control statement is arbitrarily terminated at the end 
of the last allowable image and processing continues as for a valid CS. An incomplete CS 
detected at an end-of-member is not processed, but instead is replaced by a RETURN CS 
which is processed as a valid CS. 
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3. 5.4.7 Normal Termination Phase (XEN) 

Purpose : The EM module XEN is called during the Control Statement (CS) Processing 

Phase by XCSP to process the control statement ENDCS. The ENDCS indicates that the set of 
control statements provided by the user as card image input to ANOPP (i.e., the Primary 
Input Stream) has been completely processed and ANOPP termination is desired. The process 
of terminating ANOPP upon normal completion of processing is called the Normal Termination 

Phase and is controlled by XEN. 

Input ; The M001 member on unit XSUNIT, which contains the executable form of the 
Primary Input Stream, is open to read. 

Output : There is no output since ANOPP is terminated. 

Functional Description : The Normal Termination Phase includes printing an informa- 

tive message indicating ANOPP normal termination, closing the opened member M001, and 
halting further execution. 

Logical Description : XEN is a simple module requiring no calls to lower level 

. * j iinfti : q p i via a MM call, and execution is 

modules. The required message is printed, M001 is closed 

halted via the F0RTRAN ST0P command. 

Error Philosophy: No error condition is encountered. 
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3. 5. 4. 8 Error Termination Phase (XXFMSG) 

Purpose ; The Error Termination Phase is controlled by the Executive Management 
System (EM) auxiliary module XXFMSG. It is called by any EM module which detects an error 
condition which inhibits further meaningful execution (i.e., a fatal error). 

Termination of ANOPP will result with an informative message as to the cause. 

Input : The calling module via an argument list provides the calling module name, 

defines the message number to be printed, and provides additional descriptive information. 
The same message number may be requested by several calling modules with varying descrip- 
tive information. Four arguments are provided for descriptive information with usage 
dependent upon the message. The message number range is 1-999, See Appendix C. 

Output : Message text on ANOPP output file including specified error message and a 

traceback via XEXIT. 

Functional Description ; XXFMSG identifies and prints the message requested. Mes- 
sages have two parts. The first part of all messages is fixed as follows: 

*** EXEC ERR0R (ERR0R NUMBER -— ) *** ( CALLER ) 

The second part of all messages is unique for each message number and describes the cause 
of error. 

A traceback which prints module names from the calling module to the driver XM is 
provided and ANOPP is then terminated. 

Logical Description : Identification and message printing is performed directly by 

XXFMSG. F0RTRAN WRITE statements with pre-defined F0RMATS are utilized. The General 
Utilities XTRACE and XEXIT are called to perform the traceback and the ANOPP termination 
respectively. 

Error Philosophy : The message number is validated upon entry with no further possi- 

bility of error occurrence. 
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3.5.5 Auxiliary Modules 

An auxiliary modules does not perform a function which is unique to a specific exe- 
cutive phase or group of EM modules but instead performs a function common to many EM 
modules during various executive phases. It is a general purpose module available for 
usage only by other EM modules * 

3. 5. 5.1 Fatal Error Message Writer (XXFMSG) 

Purpose : The XXFMSG module is utilized to print an informative error message when- 

ever a fatal error is encountered and detected by an EM module and to terminate ANOPP. 

XXFMSG controls the Error Termination Phase of EM and is discussed in Section 3. 5. 4. 8. 
It is called by many EM modules during the various executive phases whenever an error 
condition which inhibits further meaningful execution is detected. 

For full description of this module, see Section 3. 5.4.8. 

3. 5.5.2 Non-Fatal Error Message Writer (XXNMSG) 

Purp os e : The XXNMSG module is utilized to print an informative error message when- 
ever a non-fatal error is encountered and detected by an EM module. 

Ingut : The calling module via an argument list provides the calling module name , 

defines the message number to be printed, and provides additional descriptive information. 
The same message number may be requested by several calling modules with varying descrip- 
tive information. Four arguments are provided for descriptive information with usage 
dependent upon the particular message. The message number range is 1001-1999. 

Output : There is no output upon return to the calling module. 

Functional Description : XXNMSG identifies and prints the message required. Messages 

have two parts. The first part of all messages is fixed as follows: 

*** EXEC ERR0R ( ERR0R NUMBER ) *** ( CALLER — ) 

The second part of all messages is unique for each message number and describes the cause 


of error. 
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Logical Description : Identification and message printing is performed directly by 

XXNMSG. FORTRAN WRITE statements with pre-defined F0RMATS are utilized. 

Error Philosophy : The message number is validated upon entry and the Error Termina- 

tion Phase is invoked via the XXFMSG auxiliary if found to be invalid. 
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3.5.6 Hierarchy Charts 

A hierarchy chart is a graphical representation of the logical relationship between 
modules. Figures 1-24 are the hierarchy charts for the Executive Management System (EM). 

In general, only EM modules appear as a block entity in the charts and all EM modules 
appear at least once. The charts are in alphabetical order with respect to module name 
except for Figure 1 which is the hierarchy chart for the driver XM from which all other EM 
modules, except EM auxiliary modules, derive. A hierarchy chart for each auxiliary 
module is also among the alphabetized charts. 

A module which is not part of EM but is called by an EM module is, in general, not 
shown as a block entity but is listed at the bottom of the chart. The module may be an 
ANOPP executive module which is part of the Data Base Management System (DBM), the Dynamic 
Storage Management System ( DSM ) , or the General Utilities. It also may be a subprogram 
provided by one of the CDC operating system libraries. In either case, the module is 
generally of a service or utility nature and may be called many times by various EM 
modules. One of these service type modules may, however, be of sufficient design im- 
portance to the calling EM module that it should receive more emphasis than simply being 
listed. In these cases, the non-EM module is represented as a block entity for logical 
emphasis and is noted as such on the chart. 

Symbols and heads used in the hierarchy charts are given below: 


NAME - module name 
purpose - brief description 


indicates lower module is called by the 
higher module 


in upper right corner of module block 
indicates module is expanded as a 
separate hierarchy 


NAME 

purpose 


ORIGINAL PAGF k? 
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ANOPP Modules Called: a list of DBM, DSM, and General Utility 

Modules called by the modules in this 
figure 


CDC System Library a list of subprograms called by the 

Subprograms Called: modules in this figure and which are not 

part of ANOPP but are provided by CDC N0S 
operating system libraries 
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Figure 1 . XM Hierarchy Chart 
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Figure 2. XAT Hierarchy Chart 
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Figure 3. XBS Hierarchy Chart 
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Note... Module XCRWC is included as a block entity for emphasis but is expanded as a General Utility hierarchy in 
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Figure 5. XCAMXX Hierarchy Chart 
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Figure 6. XCSP Hierarchy Chart 
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Figure 7. XCT Hierarchy Chart 
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Figure 8. XDR Hierarchy Chart 
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Figure 9. XEX Hierarchy Chart 
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Figure 10. XFM Hierarchy Chart 
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Figure 11. XIF Hierarchy Chart 
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Figure 12. XLD Hierarchy Chart 
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Figure 13. XLDERR Hierarchy Chart 
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Figure 14. XLINK Hierarchy Chart 
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Figure 15* XMERR Hierarchy Chart 
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Figure 16, XPA Hierarchy Chart 
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Figure 17. XRT Hierarchy Chart 
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Figure 18. XRTCSS Hierarchy Chart 
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Figure 19. XRTSYN Hierarchy Chart 
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Figure 20. XTB Hierarchy Chart 
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Figure 21. XUN Hierarchy Chart 
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Figure 22. XUNERR Hierarchy Chart 
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Figure 23. XXFMSG Hierarchy Chart 
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Figure 24. XXNMSG Hierarchy Chart 
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3.6 ANOPP DATA BASE MANAGEMENT 
3.6.1 Overview 

The ANOPP Data Base Manager (DBM) provides ANOPP executive and functional modules 
with a machine independent method of storing and retrieving data on sequential and direct 
access storage devices. The following features are provided: 

1. Creation of new data units on direct access storage devices. 

2. Accessing of existing data units on direct access storage devices. 

3. Multi-data unit sequential library files for offline storage and retrieval 
of data units. 

4. Direct and sequential access of data members. 

5. Fixed format, variable format, and unformatted record types. 

6. Full record, partial record, and sequential element within record reading 
and writing of data members , 

The ANOPP DBM provides a hierarchial data structure having direct (based on the 
relative record position) and sequential accessing of logical records. These data re- 
lationships are visualized in Figure 1. 

The highest level of the hierarchy is termed the "data base 11 , which is defined as the 
universe of data for a particular ANOPP run. The universe is composed of named "data 
units" and encompasses all units referenced, even though units may be loaded, attached, 
created, and detached at various times during an ANOPP run. 

The "data unit" is the next level of the hierarchy. It is the highest level that may 
be directly referenced through ANOPP DBM control statements and subroutine calls. A Data 
Unit is physically stored on direct access storage devices and is comprised of one or more 
named "data members". A data unit name must be unique within a particular segment of an 

ANOPP run. 

Each "data member" is uniquely named within a data unit and is comprised of a set of 
logically related and organized records. Each member contains a format specification 
which defines the type and structure of the records. 
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Four record types are supported by the ANOPP DBM; fixed format, fixed format header 
with a variable number of fixed format trailers, card image, and unformatted records. 

Depending on the type, records are comprised of one or more contiguous words or 
elements. On formatted members the format specification defines the type and length of 
individual elements (integer, real double precision, complex, character string, etc.) and 
thus the length in words of records. Unformatted members have variable length records 
whose lengths are defined as they are written. 

3.6.2 DBM Control Statements 

Several ANOPP DBM Control Statements have been defined to enable the ANOPP user to 
define a data base to the ANOPP Data Base Manager and to communicate the file names used 
by the external system to the DBM. In brief, the following control statements are fea- 
tured : 


L0AD 

load data units from a sequential library; 


UNL0AD 

unload data units to a sequential library; 


ATTACH 

attach a data unit from the external system; 


DETACH 

detach a data unit from the internal system; 


CREATE 

create a new data unit; 


ARCHIVE 

permanently write-protect a data unit; 


PURGE 

detach a data unit internally and drop it from the 
system 

external 

DR0P 

release an external file name from the external system; 

TABLE 

build a table, to be accessed using Table Manager, 
member. 

on a data 


A detailed description of each control statement is provided in Section 3.5.2. 


3.6.3 Member Manager 

3. 6. 3.1 General Description 

The member manager as part of the ANOPP data management system provides basic open/ 
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close, read/write, and position functions for module writers via calls to specific member 
manager routines. These routines are: 


OPEN 


MM0PWD 

open member to write directly 


MM0PWS 

open member to write via scratch 


MM0PRD 

open member to read 

PUT 


MMPUTR 

write a record 


MMPUTW 

write a partial record on n words 


MMPUTE 

write a partial record of n elements 

GET 


MMGETR 

read a record 


MMGETW 

read a partial record of n words 


MMGETE 

read a partial record of n elements 

CLOSE 



MMCL0S 

close a member 

POSITION 



MMSKIP 

skip n records 


MMREW 

rewind member 


MMP0SN 

position member to record n 


Data members are made accessible through calls to the member manager "open" routines. 
These routines establish and maintain the control structures required for maintaining 
multiple members on a single unit. The following access modes are provided: 

1. Open for reading which allows for random and sequential retrieval of full 
and partial records ; 

2. Open for direct writing which enables direct storage of records to a data 
member on a unit; and 

3. Open for scratch writing which provides storage of records to a data member 
on a scratch unit until the member is closed. 

The number of members which may be concurrently open is limited by the amount of 
available Global Dynamic Storage and the number of allocated Data Unit Directory (DUD) 
entries. Each data unit which has one or more members open requires dynamic storage for 
a file table and buffer through which it interfaces with the computer operating system. 
Each open member also requires an Active Member Directory entry and a Member Control Block 
which are also in dynamic core. Additionally, each member opened for indirect (scratch) 
write uses a DUD entry with associated file table and buffer. 
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Three Member Manager PUT subprograms are provided which enable the user to write full 
and partial records to a data member that is open for direct or indirect write. Calls to 
these subprograms may be intermingled as required with only three limitations: 

1. MMPUTE may not be used with unformatted members, 

2. MMPUTW calls which precede MMPUTE calls must write . the number of words 
required for MMPUTE to begin writing at the beginning of the next element. 

3. MMPUTE and MMPUTW calls which immediately precede MMPUTR calls must end 
the record which they were writing. 

A member on a unit can be simultaneously open to read and write. The old version is 
available for reading until the new version is completed and closed at which time all MM 
internal links to the old version are destroyed. The new version being written (m 
"scratch” or "direct" mode) does not physically replace the old version but instead is 
written at a different location on the unit. Therefore, in reading and writing simultane- 
ously, no synchronization of PUTs and GETs is required. Any record on the old version is 
available for reading regardless of which record on the new version is being written. 

Since the open to write call is non-destructive, the open to read call may occur before or 
after the open to write call. The open to read call on this member (MM0PRD) should have a 
corresponding close call (MMCL05) before the new version of the member is closed. If it 
does not, an informative message is issued. Furthermore, the NAME argument provided to 
the open to read, subsequent gets, and corresponding close calls must not have the same 
core location (i.e., same variable name) as the NAME argument provided to the open to 
write and subsequent puts and corresponding close calls. 

Example (where UNIT1 (MEM1) is an existing member and not open currently): 

DIMENSION NAMER(3) , NAMEW( 3) 

NAMER(l) = 5HUNIT1 
NAMER(2) = 4HMEM1 
NAMEW(l) = 5HUNIT1 
NAMEW( 2) = 4HMEM1 

CALL MM0PRD (NAMER) 

CALL MM0PWD (NAMEW, other arguments) 

CALL MMPUTR (NAMEW, other arguments) 

CALL MMGETR (NAMER, other arguments) 

CALL MMCL0S (NAMER) 

CALL MMCL0S (NAMEW) 
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Three Member Manager Position subprograms are available which provide rewind , forward 
and reverse skip, and random record positioning. Usage of these routines requires that a 
member be open for read. 

The close member module (MMCL0S ) should be called for all open members prior to 
returning to ANOPP Executive control. If an executive module fails to close a member, the 
error will not be detected, subsequent use of that member will be inhibited, and unpre- 
dictable errors in subsequent executive and functional modules may occur. If a functional 
module fails to close a member, subprogram XFMMM will logically close it and issue an 
informative message. However, members which were open to write (and not closed) will not 
be entered or updated in the Data Member Directory for the particular data unit on which 
they were written. Thus, members which did not exist prior to being opened will be 
eliminated from the ANOPP universe of data and updated members will be restored to their 
pre-update condition. 

3.6. 3. 2 Subroutine Arguments 

Several subroutine arguments are common to more than one member manager subroutine. 

NAME - a three word array, the first 2 words specifying the unit and member 
names respectively. Each name is 1-8 alphanumeric characters beginning 
with an alphabetic character. The third word is reserved for the MM and 
must not be altered by the user. 

FORMAT - specifies the format of the records which will be created. It is 

given as a character string terminated with a $. The acceptable codes for 
elements which comprise the record include : 

I: integer (one word) 

RS: real single precision (floating point-one word) 

RD: real double precision (floating point-two words) 

CS: complex single precision (floating point-two words) 

L: logical (one word) 

CD: complex double precision (floating point-four words) 

Ai: character string of i characters which is assumed to be packed 

8 characters per word, 1^ i^ 132. 

$: format string terminator character. 
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Each element code is separated by a comma. A multiplier may optionally 
precede parentheses enclosing a single element or a group of elements. The 
multiplier specifies the number of times the element(s) are to be repeated. 
The character * may be used as an indefinite multiplier when preceding the 
last element(s) of the format. The * specifies an indefinite repeat of the 
element group. There are four types of formats: 


UNFORMATTED - the records are undefined format and variable length. 

A zero is coded for F0RMAT . 

ftyfd LENGTH FORMAT - The format does not contain the indefinite 
“ ™). Each record -ill be of the same length deter- 

mined by the format* 

VARIABLE LENGTH FORMAT - The format includes the indefinite multiplier 
' m The records ere varielle length depending on the nwber of 
elements 6 writ ten which may or «y not inoicde the 
repeat group. However, partial repeat groups may not be written. 

CARD IMAGE FORMAT - The format consists of "Cl" and will interpreted 
as"10A8$" It is, therefore, a special purpose fixed format 


For example: 


specifies fixed length formatted records of 10 words (10 integer 
elements ) . 

Ip™5i«c a^Ked with f«Md record of 9 ” 

^"i::,”Sg^ 0 reai single pro- 

c is ion. 

specifies formatted record of two integers flowed 

b? repealing group of 2 elements (3 words) of integer and complex 


FORMAT = 0 

then the records 


will be variable length with undefined format 


FORMAT = 2HCI 
then the records 


are fixed format card images. 
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MNR - specifies the maximum number of records to be output to a data member. 

If MNR is zero a default value of 10,000 records is used. The MNR argument 
is used by Data Member Manager in computing the size of Record Directory 
blocks which are used as indices in subsequent random and sequential record 
*'®*^*'^ eval . An attempt to write more than MNR data records to a particular 
member will result in immediate termination of the ANOPP run. 

STATUS - conditions, which are of interest to a user of Member Manager, are 
returned in this argument by open, get, and positioning subroutines. If 
STATUS is: 

0 conditions are normal for the operation involved, 

-1 Member Manager is currently positioned in the midst of a record 
or the just executed MMGETR transferred a partial record, 

-2 End of record occurred on a partial get , 

-3 End of member was detected on the last get or position operation, 

-4 Beginning of member was detected on the last position operation, 

-5 The data unit specified in the last open member request does not 

exist, and 

“6 The data member specified in the last open member request does 
not exist. 


3.6. 3. 3 Open Data Member Subroutines 


3. 6. 3. 3.1 MM0PRD - Open for Read 


Purpose : MM0PRD makes an existing data member available for subsequent random and 

sequential accessing of data. 

Format : CALL MM0PRD (NAME, IHDR, STATUS) 

Arguments : 

NAME - a three word array containing the names of the data unit and member to 
be opened. Upon returning, the names are unchanged and the third word 
contains the integer IDX to the Member Control Block. 

IHDR - a two word array which on return contains, in the first wcJrd, the length 
of the largest data record and, in the second word, the number of data 
records written on the data member. 
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STATUS - an integer less than or equal to zero is returned. If zero is returned, 
the data member was opened. A negative status indicates that the data 

member is not open. 

Description : The initial steps in opening a data unit are validation of the name 

argument and determining if the data member is in use via Data Table Manager. The name 
validation routine ( MMVNM ) fetches alternate names for both data unit and member, edits 
them for proper form (1 to 8 character alphanumeric with leading alphabetic character), 
and attempts to locate the named data unit in the Data Unit Directory (DUD). If a DUD 
entry is not found, a status of -5 is set and the open routine returns to its caller. If 
a DUD entry is found, a routine (MMVTD) is called to determine if the data member is also 
open to Data Table Manager (DTM) . If it is, ANOPP execution is terminated immediately 

with an appropriate message. 

If the data member is not open to DTM, subprogram MMI0MC is then called to increment 
the DUD entry's open member count and insure that the data unit is open. The data unit's 
Data Member Directory (DMD) is then read into core and searched for the named data member. 
If an entry for the data member is not found a -6 status is set, the open member count is 

decremented and if it is zero the data unit is closed and MM0PRD returns to its caller. 

When an entry is found, however, an Active Member Directory entry and a Member Control 
Block are established for the data member; the maximum record length and number of user 
records are retrieved from the data member’s Data Member Header; and a status of zero is 

returned to the user . 

Error Conditions : MM0PRD prints an informative message and returns a non-zero 

status to the caller if either the unit named in the open request is not in the unit 
directory or the member named is not in the member directory. 

MM0PRD aborts with a message if the member is already open to read, if the member is 

an active data table, or if an attempt to expand the member control block is unsuccessful. 
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3.6.3* 3.2 MM0PWD - Open for Direct Write 

Purpose : MM0PWD makes a data member available for subsequent sequential output 

directly to its data unit. 

Format : CALL MM0PWD (NAME, F0RMAT, MNR, STATUS) 

Arguments : 

NAME - a three word array containing the names of the data unit and member to 
be opened. Upon returning, the names are unchanged and the th.v'd 
contains the integer IDX to the Member Control Block. 

F0RMAT - a Hollerith literal specifying the number and types of data elements 

in each data record. Legal values are discussed in Subsection 3. 6. 3. 2. 

MNR - an integer number, greater than or equal to zero, which specifies the 
maximum number of data records that may be written to the data member. 

STATUS - a negative or zero integer is returned indicating, if zero, that the data 
member is open, or, if negative, not open. 

Description : The initial steps in opening a data member for direct output are 

validating the name argument and determining if the data member is in use via Data Table 
Manager. The name validation routine (MMVNM) fetches alternate names for both data unit 
and member, edits them for proper form (1 to 8 character alphanumeric with leading alpha* 
betic character), and attempts to locate the named data unit in the Data Unit Directory 
(DUD). If a DUD entry is not found, a status of *5 is set and the open routine returns to 
its caller. If a DUD entry is found, a routine (MMVTD) is called to determine if the data 
member is also open to Data Table Manager (DTM). If it is, ANOPP execution is terminated 
immediately with an appropriate message. If the data member is not open to DTM, the data 
unit’s direct write flag is checked to determine if another data member is open for direct 
writing on the data unit. If the direct write flag is set, ANOPP execution is terminated 
with an appropriate message. Otherwise, an entry is made in the Active Member Directory, 
the data unit’s direct write flag is set, a Member Control Block is built containing the 
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Data Member Header, and the open member count in the data unit's DUD entry is incremented 
(via MMI0MC) thus insuring that the data unit is open. 

Error Conditions : MM0PWD prints an informative message and returns a non-zero 

status to the caller if the unit named in the open request is not in the unit directory. 

MM0PWD aborts with a message if the data unit has been archived or is already open 
for direct write. 

3. 6. 3. 3. 3 MM0PWS - Open for Indirect Write 

Purpose : MM0PWS males a data member available for sequential output to a scratch 

data unit. When closed, the data member is copied to the data unit named in the open. 

Format : CALL MM0PWE. (NAME, F0RMAT , MNR, STATUS) 

Arguments : 

NAME - a three word array containing the names of the data unit and member uO 
be opened. Upon returning, the names are unchanged and the third word 
contains the integer IDX to the Member Control Block. 

F0RMAT - a Hollerith literal specifying the number and types of data elements in 
each data record. Legal values are discussed in Subsection 3. 6. 3. 2. 

MNR - an integer number, greater than or equal to zero, which specifies the 
maximum number of data records that may be written to the data member. 

STATUS - a negative or zero integer is returned indicating, if zero, that the data 
member is open or, if negative, not open. 

Description : The initial steps in opening a data unit are validating the name argu- 
ment and determining if the data member is in use via Data Table Manager. The name valiao 
tion routine ( MMVNM ) fetches alternate names for both data unit and member, edits them fir 
proper form (1 to 8 alphanumeric with leading alphabetic character), and attempts to 
locate the named data unit in the Data Unit Directory (DUD). If a DUD entry is not found, 
a status of -5 is set and the open routine returns to its caller. If a DUD entry is 
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found, a routine (MMVTD) is called to determine if the data member is also open to Data 
Table Manager. If it is, ANOPP execution is terminated immediately with an appropriate 
message. If the data member is not open to DTM, a scratch data unit is created, an Active 
Member Directory entry is built, a Member Control Block is built containing the Data 
Member Header, and the open member count is incremented to open both the actual and scratch 
data units. 

Error Conditions ; MM0PWS prints an informative message and returns a non-zero status 
to the caller if the uni-*: named in the open request is not in the unit directory. 

MM0PWS aborts with a message if the data unit is archived, 

3.6. 3,4 Put Subroutines 
3.6. 3.4.1 MMPUTR - Put Record 

Purpose : MMPUTR writes a complete record to a named data unit. 

Format ; CALL MMPUTR (NAME, ARRAY, NWDS) 

Arguments : 

NAME - a three word array which specifies a data member, opened to write, on which 
the record is to be written. 

ARRAY - an array containing the record to be written to the data member. 

NWDS - length, greater than or equal to zero, of the record to be written. 

Description : There are three initial validations performed by subprogram MMPUTR. 

First, a call to subprogram MMEDNM insures that the NAME argument used in calling MMPUTR 
is the same as that used to open the member and that the member is open for write. Se- 
cond, the Member Control Block (MCB) is checked to determine if the previous record was 
completed. If is was not, ANOPP execution is terminated and a message specifying the 
cause is output. Third, if the previous record was completed, the NWDS argument must be 
zero or positive. If NWDS is negative, ANOPP execution is terminated. 
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The next level of validation is dependent on the data member's format type. For 
unformatted members, no further validation is performed. For fixed format, the NWDS 
argument must equal the fixed record length from the MCB. And for variable format re- 
cords, NWDS must be equal to the length of the fixed part of the record plus an integral 
(or zero) number of fixed length trailers. 

Records are put to the member using subprogram MMPUT which builds the Record Di- 
rectory and maintains the control information in the MCB. 

Error Conditions : MMPUTR aborts with a message if the NAME argument is invalid, n 
the previous record is incomplete, if the NWDS argument is negative, or if the record to 
be written does not end on a legitimate record format boundary. 

3.6. 3.4.2 MMPUTW - Put Partial Record Words 

Purpose : MMPUTW writes a partial record of a specified number of words to a fixed 

format, variable format, or unformatted data member. 

Format : CALL MMPUTW (NAME, ARRAY, NWDS, E0R) 

Arguments : 

NAME - a three word array which specifies a data member, opened to write, on 
which the partial record is to be written. 

ARRAY - an array containing partial record to be written. 

NWDS - number of words, greater than or equal to zero, to be written from ARRAY. 

E0R - logical end-of -record flag - -TRUE, terminates the record and .FALSE, 

record is to be left open for additional partial puts. 

Description : MMPUTW performs two initial validations. First, subprogram MMEDNM 

insure, that the SME argument is valid for the put operation. Then the »WDS argument 
must not be negative. If either of these validations fails, «»OPP is terminated and a 
message describing the error is output. 

Final validation of a record length is performed when the EdP argumeht is true and 
the data member is formatted. If the data member is fixed format the total record length 
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must equal the record length implied by the format. If variable format, the total record 
length must equal the length of the fixed part of the record plus the length of an integral 
(or zero) number of fixed length trailers. 

Finally , subprogram MMPUT writes the partial record to the member, updates the con- 
trol information in the MCB, and, when E0R is true, updates the Record Directory. 

Error Conditions : MMPUTW aborts with a message if the NAME argument is invalid, if 
the record length is incompatible with the format, or if the number of words argument is 
negative . 

3.6. 3.4, 3 MMPUTE - Put Partial Record Elements 

Purpose : MMPUTE writes a partial record of a specified number of elements to a 

formatted data member. 

Format: CALL MMPUTE (NAME, ARRAY, NEL, E0R) 

Arguments : 

NAME - a three word array which specifies a data member, opened to write, on 
which the elements are to be written. 

ARRAY - an array containing the partial record to be written. 

NEL - number of elements, greater than or equal to zero, in ARRAY. 

E0R - logical end-of-record flag. .TRUE, terminates the record; .FALSE, 
record is to be left open for additional partial put requests. 

Description : MMPUTE validates the NAME argument using subprogram MMEDNM to insure 

that the data member is open to write. It then checks the format type since elements may 
not be put to an unformatted member. 

Next the NEL argument is checked to insure that it is not negative; the Format 
Specification Table (FST) index in the Member Control Block (MCB) is set by MMSFEI based 

on the number of words already put to the current record (also in the MCB); and the number 

of words required to put NEL elements to the data member is determined using MMGNWE. If 
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the end-of -record flag (E0R) is true, the total record length, including NEL elements, is 
checked against the format and if it is not valid, a message is issued and ANOPP is 
terminated. Finally, if all validations are passed, NEL elements are written to the 
member via subprogram MMPUT . 

Error Conditions : MMPUTE aborts with a message if the NAME argument is invalid, if 
the record type is unformatted (improper use of this call), if the number of elements in 
the array containing the partial record to be written is negative, if the record length is 
incompatible with the format, or if the total record length exceeds the fixed format. 

3.6. 3. 5 Get Subroutines 
3.6.3. 5.1 MMGETR - Get Record 

Pu rpose : MMGETR attempts to read a complete record from a named data member. 

Format t CALL MMGETR (NAME, ARRAY, MAXWDS, NWDS, STATUS) 

Arguments : 

NAME - a three word array which specifies a data member, opened for read, from 
which the record is to be read. 

ARRAY - an array into which the data record is to be read. 

MAXWDS - maximum number of words which may be read into ARRAY (i.e., the assumed 
length of ARRAY) must be greater than zero. 

NWDS - returned by MMGETR, integer number of words actually read into ARRAY. NWDS 
will be less than or equal to MAXWDS. 

STATUS - returned by MMGETR, integer status of the read operation: 

0 - a complete record was read. NWDS is less than or equal to MAXWDS. 

-1 - the record in ARRAY was truncated due to lack of room, NWDS equals 

MAXWDS (record length is greater than MAXWDS) and member is positioned 
to the beginning of the next record. 

-3 - the end-of -member was detected, NWDS equals zero. 


; 3.6-15 


v executive modules 


Description : MMGETR validates the NAME argument using subprogram MMEDNM to insure 

that the data member is open for reading. The MAXWDS argument is checked to insure that 
it is greater than zero. The Member Control Block (MCB) is then checked to determine if 
the member is positioned within a record. If it is the member is repositioned to the 
beginning of the next record. Subprogram MMGET is then called to read MAXWDS words into 
ARRAY. MMGET returns a status of -1 if the record length is greater than MAXWDS words, -2 

if a full record was read, and -3 if the end of member was detected. MMGETR changes a -2 

status to zero and returns the status to the user. 

Error Conditions : MMGETR aborts with a message if the NAME argument is invalid or if 

the maximum number of words which may be read into ARRAY is less than or equal to zero. 


3. 6. 3. 5.2 MMGET W - Get Partial Record - Words 


Purpose : MMGETW reads a partial record of a specified number of computer words from 

a data member. 


Format : CALL MMGETW (NAME, ARRAY, NWR, NWDS, STATUS) 


Arguments : 

NAME - a three word array which specifies a data member, opened for read, from 
which the partial record is to be read. 


ARRAY - an array into which the partial record is to be read. 

NWR - number of words to be read into ARRAY, must be greater than zero. 

NWDS - number of words actually read into ARRAY, returned by MMGETW; NWDS will 

be less than or equal to NWR. 


STATUS - integer status of the read operation, returned b\ MMGETW: 

0 - a partial record of NWR words was read, NWDS equals NWR; 

-2 - a partial record of NWDS words was read ending the record, NWDS 
is less than or equal to NWR; 

-3 - end- of -member was detected on the read, NWDS equals zero. 


Description : MMGETW validates the NAME argument using subprogram MMEDNM to insure 

that the data member is open for reading. The NWR arguments is checked to insure that it 
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is greater than zero. NWR words are then read from the current position of the data 

member by subprogram MMGET. MMGET returns a status of -1 if NWR words were read, -2 if an 

end-of-record was detected, and -3 for end-of -member. A status of -1 is changed to zero 
prior to returning to the user. 

Error Conditions : MMGETW aborts with a message if the NAME argument is invalid or if 

the number of words to be read is less than or equal to zero. 


3.6.3. 5.3 MMGETE - Get Partial Record - Elements 

Pu rpose : MMGETE reads a partial record of a specified number of elements from a 

formatted data member. 

Format : CALL MMGETE (NAME, ARRAY, MAXWDS , NER, NEL, STATUS) 

Arguments : 

NAME - a three word array which specifies a data member, opened for read, from 
which the partial record is to be read. 

ARRAY - an array into which the partial record is to be read. 

MAXWDS - maximum number of words which may be read into ARRAY (i.e., the assumed 
length of ARRAY) must be greater than zero. 

NER - number of elements to be read into ARRAY, must be greater than zero. 

NEL - number of elements actually read into array (returned by MMGETE), will be 
greater than or equal to zero. 

STATUS - integer status of the read operation, returned by MMGETE: 

0 - a partial record of NER elements was read, NEL equals NER: 

-1 - a partial record of NEL elements was read, NEL is less than NER; 

-2 - a partial record of NEL elements was read ending the record, NEL 

is less than or equal to NER; 

-3 - end-of -member was detected on the read, NEL is zero. 

Description : MMGETE validates the NAME argument using subprogram MMEDNM to insure 

that the data member is open for reading. The length of ARRAY (MAXWDS) and number of 
elements to be read (NER) are then edited for greater than zero and the format type of the 
member is checked to insure that it is formatted. If an error is found, ANOPP is termin- 
ated with an appropriate message. The Format Specification Table (FST) index is then set 
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by subprogram MMSFEI based on the number of words previously read from the current record. 
Subprogram MMGNWE is then called to obtain the number (NEL) and combined length (NWDS) of 
consecutive elements , up to a maximum of NER elements, whose combined length does not 
exceed MAXWDS words. NWDS words are then read from the member using subprogram MMGET. 
MMGET returns the STATUS and number of words actually read (NWR). If NWR is less than 
NWDS, the number of elements read (NEL) is obtained from subprogram MMGNEW. Then, if the 
STATUS does not equal -2 and NEL equals NER, STATUS is set to zero. 

Error Conditions : MMGETE aborts with a message if the NAME argument is invalid, the 

length of the record array is not greater than zero, the number of elements to read is not 
greater than zero, the data member is unformatted (misuse of this call), or if the get of 
a formatted record does not end on an element boundary. 

3.6. 3. 6 Position Subroutines 

Data Member Manager provides the following capabilities for positioning within a data 
member that is open for reading: 

1. Position to a Specified Record 

2. Position to the beginning of the Current Record 

3. Position to the beginning of the Data Member 

4. Position forward or backward a Specified Number of Records. 

3.6. 3.6.1 MMP0SN - Position to a Specified Record 

Purpose : MMP0SN positions a data member to the beginning of a data record specified 

by its numeric sequence on the member. 

Format : CALL MMP0SN (NAME, NREC, STATUS) 

Arguments : 

NAME - a three word array specifying the data member, opened for read, which is 
to be positioned. 

NREC - integer number specifying the record to which the data member is to be 
positioned. 
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STATUS - integer status of the position operation: 

0 - data member is positioned to the specified record; 

-3 - data member is at the end of the member; 

-4 - data member is at the beginning of the member. 

De scription : MMP0SN edits the NAME argument using subprogram MMEDNM to determine if 

the data member is open to read. If it is not, ANOPP is terminated with an appropriate 
message. The internal record position information in the Member Control Block (MDB) is 
reset to the beginning of the record and the current record number (CRN) in the MCB is set 
equal to the NREC argument. If NREC is greater than the number of records written to the 
member v the CRN in the MCB is set to number of records written plus one. If NREC is 
negative or equal to zero, then CRN is set to one. 

Er ror Conditions : MMP0SN aborts with a message if the NAME argument is invalid. 

3. 6 . 3. 6 . 2 MMREW - Rewind Data Member 

Purpose: MMREW positions a data member to the beginning of the first data record on 

the member. 

Format : CALL MMREW (NAME) 

Arguments : 

NAME - a three word array specifying the data member, opened for reading, which 
is to be positioned. 

Description : MMREW edits the NAME argument using subprogram MMEDNM to determine if 

the data member is open to read. If it is not ANOPP is terminated with an appropriate 
message. The internal record position information is then set to the beginning of the 
record and the current record number is set to one. 

Error Conditions : MMREW aborts with a message if the NAME argument is invalid. 

3. 6. 3. 6. 3 MMSKIP - Skip Records 

Purpose : MMSKIP positions a data member forward or backward by a specified number of 

records . 
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Format : CALL MMSKIP (NAME, NREC , STATUS) 

Arguments : 

NAME - a three word array specifying the data member, opened for reading, which 
is to be positioned. 

NREC - integer number of records to be skipped: 
if negative - skip backward NREC records; 
if positive - skip forward NREC records; 

if zero - position to the beginning of the current record. 

STATUS - integer status of the position operation: 

0 - data member is positioned to the specified record; 

-3 - data member is at the end of the member; 

-4 - data member is at the beginning of the member. 

Description : MMSKIP edits the NAME argument using subprogram MMEDNM to insure that 

the data member is open for reading. If it is not, ANOPP as terminated and an appropriate 
message is issued. The internal record position information is set to the beginning of 
the current record and NREC is added to the current record number in the Member Cbntrol 
Block (MCB). If the current record number is now negative, it is set to one and the 
STATUS argument is set to -4. If the current record number is greater than the number of 
records available on the member, it is set to the number of available records plus one and 
the STATUS argument is set to -3. This provides an end-of-member condition on a sub- 
sequent read. 

Error Conditions : MMSKIP aborts with a message if the NAME argument is invalid. 

3.6. 3. 7 MMCL0S - Close Data Member Subroutine 

Purpose : MMCL0S closes a previously open data member making it unavailable for 

subsequent access. 

Format : CALL MMCL0S (NAME) 

Arguments : 

NAME - the three word array identifying the data unit and member that was used in 
opening the data member. 
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Description : MMCL0S edits the NAME argument using subprogram MMEDNM . If the data 

member is not open, processing is terminated. If the member was open for reading, it is 
logically closed using subprogram MMCLSE . If it was open for direct write the Data Member 
Directory (DMD) is updated, the Data Member Header (DMH) is written to the data unit, the 
direct write flags in the Data Unit Directory (DUD) and Active Member Directory (AMD) 
entries are cleared, and the member is logically closed using MMCLSE. In all cases, when 
MMCLSE is called the open member count is decremented and when the open member count 
equals zero the unit is logically closed. 

The closing of a data member that is open for indirect write is a little more com- 
plex. First, the data unit may not have another data member open for direct write or 
ANOPP will be terminated. Second, the DMD and DMH must be updated and written on the 
scratch data unit that was created when the data member was opened. Third, the data 
member on the scratch unit is opened for read so it can be copied, using Data Member 
Manager, to the actual named data unit. The open member count on the scratch unit is set 
to 1 and the direct write flag is cleared. Fourth, a record buffer is requested in Global 
Dynamic core to be used in copying the member. Fifth, the Member Control Block created 
when the member was opened to write is modified to permit output directly to the data unit 
named in the open call. Sixth, the member is copied from the scratch unit to the actual 
unit, and the scratch unit is closed and discarded. Finally, the DMD and DMH are updated 
and written to the actual data unit, the member is logically closed via MMCLSE, and the 
dynamic core used in the copy operation is freed. 

Error Condition: MMCL0S aborts with a message if the NAME argument is invalid, if 

close write requested and member also open to read, if member was open to write direct and 
another member is open to write direct on the same data unit, or if insufficient Global 
Dynamic Storage is available for MMCL0S scratch copy. 
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3.6. 3. 8 Auxiliary Modules 

An auxiliary module performs a function common to several member manager modules and 
is available for use by these modules. 

3. 6. 3. 8.1 MMERR - Member Manager Error Message Writer 

Subroutine MMERR (NUM, KAMI, NAM2) processes fatal and non-fa tal errors for the 
member manager modules and the DBM control statements ARCHIVE (XAR), ATTACH ( XAT ) , CREATE 
(XCT) , DETACH (XDT), and PURGE (XPU). NUM, the integer number of the error message to be 
printed, is negative if the error is fatal and positive if the error is non-fatal. TMERR 
prints the informative error message (indicated by the absolute value of NUM) with specific 
values involved in the error condition (indicated by input values NAM1 and NAM2) . If the 
error is fatal, ANOPP is aborted by a call to XEXIT. If the error is non-fatal, a trace- 
back is performed to the major DBM module called by the user. 

3. 6. 3. 8. 2 MMVUM - Validate Data Unit and Member 

— r P 0Se : MMVUK determines if a data unit and member are available in the present 

ANOPP operating environment. 

Format : I = MMVUM (NAME) 

Arguments : 

NAME - a two word array containing the name of the data member and name of the 
unit on which it resides. 

MMVUM - returns the following integer values: 

-I - data unit does not exist; 

0 - both data unit and member exist; 

1 " data member does not exist* 

Description: MMVUM performs the same types of validations as subprogram MM0PRD; 

however, no informative messages are issued. The form of the data unit and member names 
is validated using subprogram XVNAME to insure that they are proper alphanumeric names. 

If either name is malformed an appropriate message is issued and ANOPP is terminated. 
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Alternate names for both data unit and member are fetched and the Data Unit Directory 
is searched for the named unit. If it is not found, a function value of -1 is returned to 
the caller. If the data unit is found, its Data Member Directory is read into core and 
searched for the named data member. If it is found, a function value of zero is returned. 
Otherwise,, the function’s value will be 1. 

3.6. 3*8.3 L0AD Control Statement Error Message Writer - XLDERR 

Subroutine XLDERR (NUM , NAME, IVAL, IRAY, L) processes non-fatal errors for the DBM 
control statement L0AD. 

3. 6 . 3 . 8 . 4 UNL0AD Control Statement Error Message Writer - XUNERR 

Subroutine XUNERR (NUM, NAME, IVAL, IRAY, L) processes non-fatal errors for the DBM 
control statement UNL0AB. 


3.6. 3. 9 Hierarchy Charts 

A hierarchy chart is a graphical representation of the logical relationship between 
modules. Figures 1-23 are the hierarchy charts for the member manager modules and the 
auxiliary modules. 

In general, only member manager modules appear as a block entity in the charts and 
all member manager modules appear at least once. The charts are in alphabetical order 
with respect to module name except for Figure 1, which represents the logical grouping of 
the member manager modules. A hierarchy for the auxiliary modules are also among the 
alphabetical charts. 

A module which is not part of member manager but is called by a member manager 
module is not shown as a block entity but is listed at the bottom of the chart . The 
module may be an ANOPP executive module which is part of the Executive Management System, 
the Dynamic Storage Management System, or the General Utilities. It may also be a sub 
program provided by one of the CDC operating system libraries. In either case, the module 
is generally of a service or utility nature and may be called many times by various member 
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manager modules. One of these service type modules may be of sufficient design purpose to 
the calling MM module that it should receive more emphasis than simply being listed. In 
these cases, the non-MM module is represented as a block entity for logical emphasis and 
is noted as such on the chart. 

Symbols and headings used in the hierarchy charts are given below: 


NAME 

purpose 


NAME - module name 
purpose - brief description 


r 


NAME 



J 


Represents logical module not existing as 
entity. It is used for logical groupings. 


indicates lower module is called by the 
higher module. 


implies logical grouping with no direct 
relationship 


in upper right corner of module block in- 
dicates module is expanded as a separate 
entity. 


ANOPP Modules Called: a list of DBM, DSM , and General Utility 

modules called by the modules in this figure. 


CDC System Library Subprograms Called: a list of subprograms called by the modules 

in this figure and which are not part of 
ANOPP but are provided by CDC NOS operating 
system libraries. 
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Figure 2. MMBAME Hierarchy Chart 
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Figure 3. MMBMH Hierarchy Chart 
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Figure 4. MMCL0S Hierarchy Chart 
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Figure 5. MMD0MC Hierarchy Chart 
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Figure 6. MMERR Hierarchy Chart 
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Figure 7. MMGET Hierarchy Chart 
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Figure 8. MMGETE Hierarchy Chart 
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Figure 9. MMGETR Hierarchy Chart 





Figure 10. MMGETW Hierarchy Chart 
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Figure 12. MMNWR Hierarchy Chart 
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Figure 13. MM0PRD Hierarchy Chart 
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Figure 14. MM0PWD Hierarchy Charts 
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Figure 15. MM0PWS Hierarchy Chart 
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Figure 16. MMPUT Hierarchy Chart 
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Figure 18. MMPUTR Hierarchy Chart 
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Figure 19, MMPUTW Hierarchy Chart 
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Figure 20, MMRMD Hierarchy Chart 
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Figure 21. MMSFEI Hierarchy Chart 
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Figure 22. MMVNM Hierarchy Chart 






3.6-47 


Figure 23. MMVUM Hierarchy Chart 
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3.6.4 Data Table Manager 
3. 6.4.1 Overview 

Data Tables are a special class of one-record members. To member manager they are 
unformatted, one-record members of a data unit. To table manager they are internally 
formatted table structures to be maintained in core while they are open. Allowance for 
several types of table structures will be made. The same member/table cannot be open 
simultaneously for processing by both table manager and member manager. The primary 
purpose of table manager is to maintain the table/member in core across the execution of 
several ANOPP modules and several openings and closings of the table. 

The following is a general synopsis of events in the life of a table. When first 
opened, a table is read into Global Dynamic core and its name is entered into a table 
directory. When closed, the table remains in core and is logically closed in the di- 
rectory. Subsequent opens will take place via the directory. If a table is altered 
during the time it is open in core, it should have been opened with an open alter so that 
a copy will be placed on the original member. This is necessary to preserve the integrity 
of the table under the following conditions: a) while a table is logically closed in the 

table directory, it can be removed from the directory either to make room for other tables 
or because member manager is processing the member for writing; b) when a table is removed 
from the directory, a subsequent open will read a new copy of the member into core and 
place its name in the table directory. 

The following open, close, and interpolation routines work for any type table. 
Specific table build routines are supplied for specific table types. For further informa- 
tion about the structure of specific Data Table types, see Section 3.4.2. 

All table manager routines require the NAME parameter to identify the data unit and 
member on which the table resides or will reside. NAME is a three word array with the 
following structure: 

NAME(l) unit name of the table (A8) 

NAME( 2) member name of the table (A8) 
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NAME(3) reserved word for use by table manager and other data 

management routines and not to be altered by user 

3. 6. 4. 2 Open Data Table Subroutines 

Two open data table subroutines have been provided to give the user the ability to 
specify at open time whether a table is to be altered or not altered during processing . 

A data table that is opened with alter permission will be rewritten on its data member 
when closed. One open without alter permission is assumed to be intact and is not re- 
written. When a data table is closed it is retained in global dynamic core as an inactive 
table so that subsequent opens need not reread it. 

3. 6. 4. 2.1 TM0PNA - Open with Alter Permission 

Purpose: TM0PNA requsts that an ANOPP data table be opened with permission to alter. 

Format: CALL TM0PNA (NAME) 

Arguments : 

NAME - a three word array containing the names of the data unit and member on 
which the data table resides. On return from TM0PNA , the third word 
contains the IDX to the data table in Global Dynamic core. 

Desc ription : TM0PNA calls subprogram TMT0PN passing the NAME argument and a logical 

alter flag which is set to true. TMT0PN performs validations to insure that the data 
table is not already open to Data Table Manager (DTM) or Data Member Manager (DMM). It 
then searches the inactive table chain in the Data Table Directory for the named table. 

If the table is found, its entry is linked into the active table chain. Otherwise, sub- 
program TMM0PN is called to read the table into global dynamic core and build an active 
table entry. The IDX of the table is then swapped into the third word of the NAME argument 
the negation of the IDX of the NAME argument is stored in the DTD entry; and the table is 
opened for use. 

Error Conditions : TM0PNA aborts with a message if the table is already open to Table 

Manager or Member Manager. 


3.6-49 



EXECUTIVE MODULES 


3. 6. 4. 2. 2 TM0PN - Open Without Alter Permission 

Purpose : TM0PN requests that an ANOPP data table be opened without permission to 

alter. 

Format : CALL TM0PN (NAME) 

Arguments ; 

NAME - a three word array containing the names of the data unit and member on 
which the data table resides. On return from TM0PN, the third word 
contains the IDX to the data table in global dynamic core. 

Description : TM0PN calls subprogram TMT0PN passing the NAME argument and a logical 

alter flag which is set to false. TMT0PN performs validations to insure that the data 
table is not already open to Data Table Manager (DTM) or Data Member Manager (DMM). It 
then searches the inactive table chain in the Data Table Directory for the named table. 

If the table is found, its entry is linked into the active table chain. Otherwise, 
subprogram TMM0PN is called to read the table in global dynamic core and build an active 
table entry. The IDX of the table is then swapped into the third word of the NAME argu- 
ment; the IDX of the NAME argument is stored in the DTD entry; and the table is opened for 
use. 

Error Conditions : TM0PN aborts with a message if the table is already open to Table 

Manager or Member Manager. 

3. 6.4.3 TMCL0S - Close Data Table Subroutine 


Purpose : TMCL0S closes a data table. 

Format : CALL TMCL0S (NAME) 

Arguments : 

NAME - a three word array containing the names of the data unit and member on 
which the data table resides, and the IDX to the data table. 
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Description : TMCL0S locates the entry for the data table in the active table chain 

in the Data Table Directory (DTD) and checks the NAME argument to insure that it matches 
the NAME argument used in opening the table. If the table was opened to alter, it is 
rewritten to its data member. It is then logically closed by swapping its IDX from the 
NAME argument into its DTD entry and linking the DTD entry into the inactive table chain. 

Error Conditions : TMCL0S aborts with an error message if the table being closed was 

not open, if the closing name argument is not the same as the opening argument, or if the 
data structure being closed is not a data table. 

3 .6. 4. H TMTERP - Data Table Interpolation 

Purpose : Retrieve an interpolated value of a dependent variable from a data table 

which is currently open. 

Format : CALL TMTERP (NAME, ITYPE , X, Y, Z, ANS, ISTAT) 

Argument s : 

NAME - three word array with the following structure : 

NAME(l) - unit name of the table 

NAME( 2) - member name of the table 

NAME( 3) - reserved; not to be altered by user. 

ITYPE - type of interpolation required: 

ITYPE =0 no interpolation permitted 

ITYPE = 1 linear interpolation requested 

X,Y,Z values of the independent variables for which the corresponding dependent 
variable value is desired. 

ANS - retrieved value if ISTAT = 1; otherwise contents unaltered. 

ISTAT - status return: 

ISTAT = 1 request complete; ANS contains dependent variable value 

desired 

ISTAT = 0 request not completed; ANS does not contain dependent 

variable value desired. 

Description : TMTERP module attempts to retrieve from the Data Table specified by 

NAME the desired dependent variable value. 
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TMTERP validates that (1) the table is open, (2) the table type found in the table is 
valid , (3) the interpolation procedure requested ( I TYPE) is valid for this table, and (4) 
the number of independent variables found in the table is within range. If no error has 
been detected in the validations, an attempt is made to retrieve the desired value. 

If the dependent variable is not in the table, an interpolated value will be returned 
if ITYPE does not equal zero. If the dependent variable is outside the range of the 
table, extrapolation procedures will or will not be used according to the extrapolation 
instructions found within the table. (These instructions are established by the user at 
the time the table is built.) 

The user will be informed via ISTAT if the dependent variable value desired has been 
retrieved. The user must insure that the type of X, Y, 2, and ANS variable correspond to 
the variable types expected by the table. 

Error Conditions : TMTERP prints an error message and returns to the caller with 

request not filled if the requested interpolation procedure is invalid. TMTERP aborts 
with a message if the number of independent variables found in the data table is out of 
range, if the table type is invalid, or if an error was detected in the table edit. 

3. 6.4. 5 Data Table Building 

Since data tables may be built m a functional module, subroutines are provided which 
permit the user to build tables of the type supported by table manager (see Section 3.4.2 
Data Table Types). Tables may also be built in the control statement stream by using the 
TABLE CS (see the TABLE CS description in Section 3.5). 

3.6.4. 5.1 TMBLD1 - Build Type 1 Table 

Purpose : Build data table of structure type 1* 

Format: CALL TMBLD1 (NAME, NINT, INT, ITYPDV, NIND, IDSCRP, II, 12, 13, IDV, IERR) 

Arguments : 

NAME - three word array with the following structure: 
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NAME(l) - unit name of table 

NAME(2) - member name of table 

NAME(3) - reserved; not to be altered by user. 

NINT - number of elements in array containing interpolation procedures accept- 

able on this table. 

INT - array containing integer codes of interpolation procedures acceptable 

on this table. Valid codes are: 

0 - no interpolation 

1 - linear interpolation 

ITYPDV - type of dependent variable. Valid values are: 

1 - integer 

2 - real single precision 

3 - real double precision 

NIND - number of independent variables in this table -- 1, 2 or 3. 

IDSCRP - array of dimension NIND*4 containing a description of the NIND inde- 

pendent variables. 

(4*1-3) F0RMAT of the Ith independent variable: 

0 - ordered position from one to IDSCRP( 4*1-2 ) . This 

variable value array does not exist 

1 - integer 

2 - real single precision 

3 - real double precision 

(4*1-2) Integer number of Ith independent variable (.GE.O) 

(4*1-1) Interpolation procedure if value desired is greater than 
the largest value of the Ith independent variable 

0 - no interpolation 

1 - use closest independent variable value 

2 - extrapolate (linear) 

(4*1) Interpolation procedures if value desired is less than the 

smallest value of the Ith independent variable (same values 
as above) 

11,12,13 - start location of arrays containing independent variable values as 

defined for data table type 1. If an independent variable is format 
type zero for ordered position, then the corresponding array is ignored. 

IDV - NIND dimensional array of dependent variable values. 

I ERR - indicates if table was built: 

I ERR =0 no error detected; table was built 

IERR = -1 error detected; table was not built 
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Description : The TMBLD1 module builds a Data Table Type 1* The input values MINT, 

INT, ITYPDV, NIND, and IDSCRP are edited to insure they are in the range expected. The 
independent variable arrays are validated to insure they are in monotonic sequence. If no 
errors are detected in the edit, a Type 1 table structure is generated and put on the 
unit /member specified by NAME. The table is not maintained in core but is available for 
processing via TM0PN. If a duplicate table exists, it is replaced. A table by this name 
may not currently be open either by a table manager or a member manager call. The user is 
informed via IERR if an error occurred which prevented the building of the table. 

Error Conditions : TMBLD1 writes an error message if the unit the table was to be 
built on is not in the unit directory, if there is insufficient core to build a table, or 
if errors were detected in editing the values to be used in building the table. 

3. 6. 4. 6 Auxiliary Modules 

An auxiliary module performs a function common to all table manager modules and is 
available for use by these modules. 

3. 6. 4. 6.1 TMERR - Table Manager Error Message Writer 

Subroutine TMERR (NUM, NAME, IV AL, IRAY, L) processes fatal and non-fatal errors for 
the table manager modules and the DBM control statement TABLE (XTB). NUM, the integer 
number of the error message to be printed, is negative if the error is fatal and positive 
if the error is non-fatal. TMERR prints the informative error message (indicated by the 
absolute value of NUM) with the specific value(s) causing the error condition (indicated 
by input values NAME, IVAL, IRAY). If the error is fatal, ANOPP is aborted by a call to 
XEXIT. If the error is non-fatal, a traceback is performed to the major table manager 
module called by the user. 
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3. 6. 4. 7 Hierarchy Charts 

A hierarchy chart is a graphical representation of the logical relationships between 
modules. Figures 24-27 are the hierarchy charts for the table manager modules and the 
auxiliary module. 

In general, only table manager modules appear as a block entity in the charts and all 
table manager modules appear at least once. The charts are in alphabetical order with 
respect to module name except for Figure 24 which represents the logical grouping of the 
table manager modules. A hierarchy for the auxiliary module is also among the alpha- 
betized charts. 

A module which is not part of table manager but is called by a table manager module 
is not shown as a block entity, but is listed at the bottom of the chart. The module may 
be an ANOPP executive module which is part of Member Manager, the Dynamic Storage Management 
System, or the General Utilities. It may also be a subprogram provided by one of the CDC 
operating system libraries. In either case, the module is generally of a service or 
utility nature and may be called many times by various table manager modules. 

Symbols and headings used in the hierarchy charts are given below: 


NAME - module name 
purpose - brief description 


represents logical module not existing as 
entity. It is used for logical groupings. 


indicates lower module is called by the 
higher module. 


implies logical grouping with no direct 
relationship. 


In upper right comer of module block 
indicates module is expanded as a separate 
entity 
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ANOPP Modules Called: a list of DBM, DSM , and General Utility _ 

modules called by the modules in this figure. 


CDC System Library Subprograms Called: a list of subprograms called by the modules 

in this figure and which are not part of 
ANOPP but are provided by CDC NOS operating 
system libraries. 
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Figure 24. Table Manager Hierarchy Chart 
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Figure 25. TMERR Hierarchy Chart 
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Figure 26. TMINEX Hierarchy Chart 
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3.7 DYNAMIC STORAGE MANAGEMENT SYSTEM (DSM) 

3.7,1 Overview 

The ANOPP Dynamic Storage Manager (DSM) provides a method of allocating and releasing 
core storage within ANOPP. The boundaries of the storage area to be managed are defined 
to be from the end of the longest overlay segment of the presently executing executive or 
functional module to the last word of the field length. 

Obviously, as different executive and functional modules are called into execution, 
the available free storage fluctuates. Therefore, in order to provide for executive 
inter-module communication and for the storage of ANOPP directories and tables, a section 
of free storage, known as "Global Dynamic Storage" (GDS), has been defined. The starting 
address of GDS is established by the Executive Initialization Phase (XBS) and must be 
beyond the longest segment of the largest module which will be executed by a particular 
ANOPP run. 

The rest of the free storage is available for intra-module usage as "Local Dynamic 
Storage" (LDS) . LDS begins with the word following the longest segment of a particular 
module and ends at the start of GDS. 

Addressing of Dynamic Storage by the user is accomplished by indexing relative to a 
fixed common block - XAN0PP . The FORTRAN statement C0MM0N/XAN0PP/IX( 1 ) must be included 
in every program and subroutine that directly references dynamic storage. DSM will then 
return an index (IDX), relative to XAN0PP, whenever a block of dynamic storage is reserved 
(DSMG). The variable containing the index is thereafter reserved for DSM use. The con- 
tents of IDX must not be changed by the user unless the reserved block has been released 
(DSMF) or another variable is provided to DSM (DSMS). 

At the beginning of execution, all core in the dynamic storage areas belong to two 
free blocks, one for LDS and one for GDS. As blocks are reserved and released during 
execution, dynamic storage will be divided into a number of separate blocks, some reserved 
and some free. To minimize fragmenting of dynamic storage, DSM will collapse a block of 


ESSfJiSS 


3.7-1 



EXECUTIVE MODULES 


dynamic storage into adjacent free blocks, when it is released, to form a single free 
block. 

still, fragmentation of free blocks may reach the point where a single block of the 
requested size cannot be reserved for the user. When this occurs, the free blocks will be 
consolidated into one free block. This occurs automatically without the user's knowledge 

and will involve the relocation of reserved blocks and the updating of their respective 
indices . 

If the user wishes to inhibit consolidation, he may "lock" dynamic storage using a 
DSM utility (DSML). When the situation requiring the lock is passed, the user must then 
'unlock" dynamic storage (DSMU) to re-enable consolidation. The results of absolute 
addressing schemes in unlocked dynamic storage are unpredictable and best avoided. 

Finally, DSM provides a utility to expand a reserved block (DSMX). DSMX will attempt 
to expand a reserved block by reserving any adjacent free storage. If that is not possi- 
ble, DSMX will reserve a new, larger block, relocate the contents of the original block, 
and update the user's IDX. DSMX will relocate the specified block regardless of whether 
dynamic storage is locked or unlocked. 

3-^.2 Dynamic Storage Structure 

The Dynamic Storage Management System maintains two distinct storage areas in the 
free storage area defined as the block of core from the end of the longest overlay segment 
of the presently executing executive or functional module to the last word of field length. 

The area known as Global Dynamic Storage (GDS) begins somewhere beyond the longest 
segment of the largest module executed during the ANOPP run, and ends with the last word 
of field length. The length of GDS is determined by the LENGL parameter on the AN0PP 
control statement, if specified, or a system default that provides a minimum length 
necessary for ANOPP to run. GDS is established during the Initialization Phase (XBS) for 
the life of the ANOPP run. 
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The area known as Local Dynamic Storage (LDS) begins with the first word following 
the overlay segment in current execution and uses all storage not already allocated for 
GDS . LDS is initialized by each functional or executive module according to the length of 
its overlay segment. The positioning of LDSA is accomplished by loading a labeled common 
block after the longest overlay segment of the module. The definition and placement of 
this common block is the responsibility of the user. The name of this common block must 
be unique and by convention begins with LDSA. Each functional or executive module that 
initializes LDS must also release LDS before control passes to another module. 

The structure of the two storage areas LDS and GDS is identical. Each has three 
header control words and a single trailer control word that identify the storage type (GDS 
or LDS), give the pointer to the first block in the free storage chain, and delimit the 
storage area (see Dynamic Storage Control Words Section). 

As the free storage in GDS and LDS is reserved by users, and subsequently released, 
the free storage becomes fragmented. In order to keep track of these fragmented free 
storage blocks, each storage area maintains its own free storage chain. As part of this 
chain, each free block contains a forward and a backward pointer to other blocks in the 
chain . 

3. 7. 2.1 Dynamic Storage Control Words 

The Dynamic Storage control words include three header words and a single trailer 
word on both Global Dynamic Storage and Local Dynamic Storage. These header and trailer 
control words are initialized by the DSMI module at the time the Global Dynamic and Local 
Dynamic storage areas are initialized by DSMI. 

The header control words are the three words beginning with the first word of the 
dynamic storage area (GDS or LDS). Word 1 is initialized by DSMI with the dynamic storage 
type ( 3HGDS or 3HLDS ) . Word 2 is initialized by DSMI with the relative address of the 
first block in the free storage chain. Word 3 is initialized by DSMI with a convenient 
bit pattern (all bits on) for delimiting the storage area. 


3.7-3 



EXECUTIVE MODULES 


The trailer control word is also initialized by DSMI with a convenient bit pattern 
(all bits on) for delimiting the storage area. 


EXAMPLE : 


IX( SADDR) 

LDS or GDS 

IX( SADDR+1) 

SADDR+3 

IX( SADDR+2) 

77777777777777777777777777777777777777 

Storage words 
available to 
user 

(This area holds blocks 
reserved by users of the 
system, plus the free 
storage chain. ) 

IX ( EADDR) 

77777777777777777777777777777777777777 


where SADDR and EADDR are parameters from the /XDSMC/ common block. 

SADDR is the relative address of the start of dynamic storage area. 

EADDR is the relative address of the end of dynamic storage area. 

3.7. 2.2 Reserved Block Control Words 

The reserved block control words include three header words at the beginning of each 
reserved block and one trailer word at the end of the block. 

Word 1 of the header control words of a reserved block is defined as the complement 
of the length of the reserved block. In this case, length does not include the reserved 
block control words. Word 2 of the header control words is defined as the name (1-6 
characters) of the user that reserved the block. User name is taken from the USER para- 
meter on the DSMG call to reserve the block Word 3 of the header control words is set to 
the relative address of the user's IDX variable. 

The trailer control word of a reserved block, like the first header control word, is 
set to the complement of the block length. 

Reserved block control words are defined by the DSMG module when the block is re- 
served. 
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where ILCC is an integer function that determines the address of the IDX 
variable relative to /XAN0PP/ . 

Blocks may be reserved in either Global Dynamic Storage or Local Dynamic Storage. 

After initialization of Global Dynamic Storage and Local Dynamic Storage, and one block has 
been reserved with IDX = IDXA and length LENGTHA in GDS, the storage area appears as 
follows : 
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IX(LSADDR) 
IX(LSADDR+1 ) 
IX(LSADDR+2) 


IX(LEADDR) 
IX(GSADDR) 
IX(GSADDR+1 ) 
IX(GSADDR+2) 
IX( IDXA-3 ) 
IX( IDXA-2 ) 
IX(IDXA-l) 


IX( IDXA+LENGTHA) 


IX(GEADDR) 


LDS 

LSADDR+3 

777777777777777777777777777777777777777 

FREE STORAGE 

777777777777777777777777777777777777777 

GDS 

GSADDR+3+LENGTHA+4 

777777777777777777777777777777777777777 

-LENGTH A 

USER 

IL0C( IDXA) 

RESERVED BLOCK 

-LENGTH A 

FREE STORAGE 

777777777777777777777777777777777777777 


where IL0C returns the address of the IDXA variable relative to /XAN0PP/ and 

where /XDSMC/ common block parameters have the following definitions: 

LSADDR - LDS start relative to /XAN0PP/ 

LEADDR - LDS end relative to /XAN0PP/ 

GSADDR - GDS start relative to /XAN0PP/ 

GEADDR - GDS end relative to /XAN0PP/ . 

3. 7. 2. 3 Free Storage Control Words 

Free storage in GDS and LDS is maintained in a chain for internal control. There- 
fore, each free block header contains a forward pointer and a backward pointer that 
establishes the block’s place in the chain. The free block control words include a three- 
word header and a trailer word. 
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Word 1 of the header control words contains the length of the free storage block. 
This length excludes the free block control words . Word 2 of the header contains the 
address relative to /XAN0PP/ of the next block (forward pointer) in the free chain. Word 
3 of the header contains the address relative to /XAN0PP/ of the previous block in the 
chain (backward pointer). 

The trailer control word of a free block, like word 1 of the header, contains the 
length of the block. This length excludes control words. 

When either storage area GDS or LDS is initialized, all words in that storage area 
belong to the free storage chain, which has only one block. The DSM I module defines the 
control words for the single block in the free storage chain as well as the control words 
for the storage area. 


EXAMPLE: 


IX (AVAIL) 
IX(AVAILtl) 
IX( AVAIL+2 ) 


IX( AVAIL+LENGTH+3) 


FREE BLOCK STRUCTURE 


LENGTH 


NEXT 


PREVIOUS 


LENGTH 


LENGTH 


where AVAIL is the address relative to /XAN0PP/ of free block 


3 . 7.3 Dynamic Storage Management System User Modules 

Although dynamic storage is intended for use by the ANOPP Executive and Data Manage- 
ment Systems, functional modules may also make use of DSM. The calling sequence for most 
DSM subroutines is as follows: 

CALL DSMx (USER, TYPE, IDX, P^..^) 


0- iiO-jv • »AC4Si 

of FOOE omrjmi 




EXECUTIVE MODULES 


USER 


TYPE 


IDX 


integer variable defining name of calling module as a one to six character 
Hollerith constant 

defines the dynamic storage type (LDS or Local Dynamic Storage and GDS 
for Global Dynamic Storage) 

user defined integer variable which will contain the location of a block 
of dynamic storage relative to a reference point. For the ANOPP system, 
the reference point is the /XAN0PP/ common block. The address of IDX 
will be stored in the block of dynamic storage reserved for USER, and 
the index stored at that address will be updated whenever the dynamic 
storage block is moved due to a consolidation request, 
miscellaneous parameters required by the specific DSM module. 


The USER parameter required by most DSM modules is the key to ownership of a reserved 
block of storage. When a storage block is reserved, the name of the user making the re- 
quest is stored in the block. Subsequent operations on that block of storage are per- 
mitted only for the appropriate user. 


3,7. 3.1 DSMB - Determine Dynamic Storage Boundaries 


Purpose : To retrieve the start and end addresses of Local Dynamic Storage (LDS) for 

subsequent initialization of LDS by DSMI. 

Format: CALL DSMB(A) 


Arguments : 


A - array in labeled common LDSAxxx, supplied by the user, which has been reserved 
for Local Dynamic Storage. On output, A(l) contains the index relative to 
/XAN0PP/ to start of Local Dynamic Storage. A(2) contains the index relative 
to /XAN0PP/ to end of Local Dynamic Storage. 
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Description : The DSMB module should be called when a module is integrated into the 

ANOPP system to get the start and end addresses of Local Dynamic Storage, On entry, 

Global Dynamic Storage must already be initialized. 

Labeled common LDSAxxx is loaded immediately after the user’s longest module to give 
him full benefit of the available storage. DSMB calculates the start of the array A in 
labeled common LDSAxxx as an index relative to /XAN0PP/ and stores the index in the first 
word of the array. This is the index to the beginning of LDS. 

DSMB calculates the end of LDS as an index relative to /XAN0PP/ and stores the index 
in A( 2 ) . The end of LDS is calculated as the address of the word immediately preceeding 
the start of Global Dynamic Storage. 

With the start and end address of LDS stored in the first and second word of array A, 
the user may initialize LDS via DSMI. 

Error Conditions : DSMB aborts with a message if LDS and GDS boundaries overlap. 

3.7. 3. 2 DSMD - Dynamic Storage Dump 

Purpose : To dump the contents of Global or Local Dynamic Storage or of a single 

reserved block. 

Format : CALL DSMD (USER, TYPE, IDX) 

Arguments : 

USER - one to six-character name of user for dynamic storage area or reserved 
block. 

TYPE - three-character code indicating storage type ( 3HGDS or 3HLDS). 

IPX - index relative to IX of reserved block to be dumped, or zero, if entire 

storage area is to be dumped. 

Description : The DSMD module should be called to dump all dynamic storage or a 

single reserved block. Prior to performing the dump, DSMD validates the USER and TYPE 
arguments for a dynamic storage dump or USER, TYPE, and IDX for a reserved block dump. 
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DSMD prints the contents of the dynamic storage area control words including storage 
type, first free block pointer, dynamic storage, start address, and end address. Then the 
contents of the storage area or the reserved block are dumped. For the dump of an entire 
storage area , only the contents of control words are printed for free blocks , while all 
words in reserved blocks are printed. 

Error Conditions : DSMD aborts with a message if the dynamic storage type is not 

initialized, if the dynamic storage type is invalid, if the user is invalid, or if the IDX 
is invalid. 

3.7. 3.3 DSMF - Free a Reserved Block of Dynamic Storage 

Purpose : To free a block of dynamic storage previously reserved by a call to DSMG. 

Format : CALL DSMF( USER, TYPE, IDX ) 

Arguments : 

USER - one to six-character name of user requesting to free the block residing 
at the address specified by IDX in storage area identified by TYPE. 

TYPE - three-character code identifying storage area where block is to be freed 
resides. 

IDX - index relative to /XAN0PP/ for reserved block that is being freed. 

Description : The DSMF module frees a reserved block and returns it to the free 
storage chain making it available for use. However, before freeing the block, DSMF 
validates that the user freeing the block is the same user that reserved the block and 
that the storage type and IDX are valid. 

The header and trailer control words of the reserved block (see Section 3.7.2) are 
defined to make the block part of the free storage chain. The control words will reflect 
block size and forward and backward pointers to the free storage chain. 

If either, or both, of the blocks bordering the newly freed block is (are) also a free 
block, the newly freed block is collapsed into the adjacent free block to form a larger 
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free block. Control words for the newly formed block are redefined to reflect the new 
size and adjustment in the forward and backward pointers to the chain. 

Error Conditions : DSMF aborts with a message if there is an invalid user* dynamic 

storage type or IDX. 


3. 7. 3. 4 DSMG - Get A Block of Dynamic Storage 


Purpose : To obtain a block of dynamic storage from the free storage chain, reserve 

it for the user, and return the IDX of the reserved block. 

Format ; CALL DSMG( USER, TYPE, IDX, MIN, MAX, LEN) 


Arguments : 

USER - one to six-character name of user reserving a block. 

TYPE - three-character code indicating storage area where block should be 

reserved C 3HGDS or 3HLDS), 

IDX - (OUTPUT) address relative to /XAN0PP/ for reserved block. IDX points 
to first usable word of block (first word following reserved block 


header ) . 

MIN - minimum number words of dynamic storage required by user. 

MAX - maximum number words of dynamic storage desired by user. 

LEN - (OUTPUT) length of dynamic storage block reserved for user. Length 
excludes reserved block control words. If there was an insufficient 
amount of free storage available to satisfy user's request, the LEN 
parameter is set to zero on output. 


Des cription : The DSMG module attempts to locate and reserve a block of dynamic 

storage that will satisfy the user’s requirements. DSMG searches the free storage chain 
for a free block that will satisfy the user’s maximum request. 

If such a block is found, the maximum number of words requested is reserved for the 
user, and the reserved block control words are defined accordingly* The address relative 
to /XAN0PP/ of the reserved block is returned to the user in the IDX variable. 
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If the entire free block is used in allocating the reserved block, then the free 
block is removed from the free storage chain. In order to remove a block from the free 
chain, the forward pointer of the preceeding block in the chain and the backward pointer 
of the next block in the chain are redefined to point to each other. This completely 
removes the block from the free chain. 


EXAMPLE : Assume that on entry to DSMG Local Dynamic Storage has the following 

configuration. 


IX(LSADDR) 


IX(AVAILA) 


IX(IDXB) 


IX(AVAILC) 


LDS 

AVAILAC1ST FREE BLOCK) 

7777777777777777777777777777777777777 

LENGTH A 

AVAILC( FORWARD POINTER) 

LSADDR( BACKWARD P0INTER) UJ 

FREE BLOCK A OF LENGTH LENGTHA 

LENGTHA 

-LENGTHB 

USERB 

IL0C( IDXB ) 

RESERVED BLOCK B OF LENGTH 
LENGTHB 

-LENGTHB 

LENGTHC 

ZERO (FORWARD POINTER) (2) 

AVAILA (BACKWARD POINTER) 

FREE BLOCK C OF LENGTH LENGTHC 

LENGTHC 

777777777777777777777777777777777777777 


IX(LEADDR) 

^The backward pointer of the first block in the free chain always points to the 
start of the dynamic storage area. 

( 2 ) 

The forward pointer of the last block in the free chain always contains zero. 
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Also assume that the user requests a block where MIN = MAX = LENGTHA. Then DSMG 
uses all of free block A and removes block A from the free chain. Then LDS has the follow- 
ing configuration. An * indicates a changed entry. 


IX (LSADDR) 

LDS 


AVAILC 


77777777777777777777777777777777777777 


-LENGTHA 


USERA 


IL0C(IDXA) 

IX(IDXA) 

RESERVED BLOCK A 
OF LENGTH LENGTHA 


-LENGTHA 


-LENGTHB 


USERB 


IL0C(IDXB) 

IX(IDXB) 

RESERVED BLOCK B 
OF LENGTH LENGTHB 


-LENGTHB 

IX(AVAILC) 

LENGTHC 


ZERO (FORWARD POINTER) 


LSADDR (BACKWARD POINTER) 


TREE BLOCK C 
OF LENGTH LENGTHC 


LENGTHC 

IX( LEADDR) 

77777777777777777777777777777777777777 


In the example above, IL0C is a function that returns an address relative to /XAN0PP/, 
and /XDSMC/ parameters are defined as follows: 

LSADDR - LDS start address relative to /XAN0PP/ 

LEADDR - LDS end address relative to /XAN0PP/ 
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However, if only a portion of the free block is used in allocating a reserved block, 
then the free block maintains its place in the free chain but is reduced in size. Control 
words for the reduced free block are redefined to reflect the block's reduced size. In 
addition, the forward pointer of the preceeding block in the chain and the backward 
pointer of the next block in the chain are redefined to reflect the reduced free block's 
next location. 

EXAMPLE : Assume that on entry to DSMG local dynamic storage looks exactly like it 

did at the beginning of the previous example. Also assume that the user requests a block 
where MIN = MAX < LENGTHA. Then DSMG reserves only a portion of free block A, and LDS has 
the following configuration. 
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IX(LSADDR) 


IX(IDXX) 


IX ( AVAILA ' ) 


IX(IDXB) 


IX(AVAILC) 


IX(LEADDR) 


LDS 

AVAILA' 

77777777777777777777777777777777777 

-LENGTHX 

USERX 

ILOC(IDXX) 

RESERVED BLOCK X 
OF LENGTH LENGTHX 

-LENGTHX 

( LENGTHA-LENGTHX-4 ) 

AVAILC (FORWARD POINTER) 

LSADDR (BACKWARD POINTER) 

REDUCED FREE BLOCK A 
OF LENGTH LENGTHA-LENGTHX-4 

(LENGTHA-LENGTHX-4) 

-LENGTHB 

USERB 

ILOC(IDXB) 

RESERVED BLOCK B 
OF LENGTH LENGTHB 

-LENGTHB 

LENGTHC 

ZERO (FORWARD POINTER) 

AVAILA' (BACKWARD POINTER) 

FREE BLOCK C 
OF LENGTH LENGTHC 

LENGTHC 

77777777777777777777777777777777777 


where IL0C and /XDSMC/ parameters LEADDR and LSADDR are defined in the previous example 


nOTi Q7JAIOT 
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If attempts to find a free block that will satisfy user's maximum request fail, but 
there are enough words in all fragmented free blocks combined to provide at least the 
minimum request, then a consolidation of free storage is performed* 

After consolidation, the largest block in the free chain is examined to see if it 
satisfies the maximum request. (Note that if the dynamic storage area was locked, the 
consolidation is a null process and the storage area is unchanged. However, if the 
consolidation is actually accomplished, then all available words in the free chain have 
been consolidated into a single block.) If the free block satisfies the maximum request, 
all or part of the block is reserved for the user. If the free block satisfies only 
minimum, or some value between minimum and maximum, then all or part of the free block is 
reserved accordingly. 

If all attempts fail to satisfy the user's request, the block length LEN returned to 
user is set to zero. 

Error Conditions : DSMG aborts with a message if an invalid storage type is requested, 

if the storage type requested is not initialized, if the minimum block size requested 
exceeds maximum block size requested, if LDS or GDS has been overlayed, or if the minimum 
or maximum block size requested is negative or zero. 

3. 7. 3. 5 DSMI - Initialize Dynamic Storage 

Purpose : To initialize the control words for the specified dynamic storage type. In 

addition, to initialize the control words for the single free block in the free storage 
chain for the dynamic storage type initialized. 

Format: CALL DSMI(USER, TYPE, START, END) 

Arguments : 

USER - one to six-character name of user requesting initialization* 

TYPE - three-character code indicating storage type to be initialized ( 3HGDS or 

3HLDS). 
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START - integer variable containing the absolute address of the start of dynamic 
storage . 

END - integer variable containing the absolute address of the end of dynamic 
storage. 

Description : The DSMI module must be called to initialize a dynamic storage area 

before that storage area may be used. DSMI initializes the dynamic storage control words 
described in Section 3. 7. 2.1 Dynamic Storage Control Words, and the free block control 
words described in Section 3. 7. 2. 3 Free Storage Control Words. 

Error Conditions : DSMI aborts with a message if the storage area being initialized 

has already been initialized, if the start address for the storage area is invalid, if the 
user requesting initialization is invalid, if there is insufficient storage length for 
initialization, or if LDS/GDS boundaries overlap. 

3.7. 3. 6 DSML - Lock Dynamic Storage 

Purpose : To prohibit consolidation of fragmented dynamic free storage. 

Format : CALL DSML(USER, TYPE) 

Arguments : 

USER - one to six-character name of user imposing lock condition on dynamic storage. 

TYPE - three character code indicating dynamic storage on which lock condition is 

being imposed. 

Description : The DSML module increments the user lock against consolidation of free 

storage for the dynamic storage area specified. However, before incrementing the user 
lock, DSML does a consolidation of free storage. The consolidation relocates all reserved 
blocks to contiguous words of storage immediately following the storage area's control 
words. This forces all free words of storage, however fragmented, into a single free 
block. 

If DSML has been called previously, such that the user lock has already been incre- 
mented, then the consolidation becomes a null process and DSML increments the user lock 

again . 
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Error Conditions : DSML aborts with a message if the storage type is invalid. 

3.7. 3.7 DSMQ - Query to Obtain Size of Largest Available Block 

Purpose : To return the length of the largest amount of free storage available. 

Format : CALL DSMQ(USER, TYPE, LEN) 

Arguments : 

USER - one to six- character name of user making inquiry. 

TYPE - three-character code indicating dynamic storage area being queried. 

LEN - (OUTPUT) length of largest amount of free storage available in storage 

area specified. The LEN parameter will be set to zero if no free storage 
is available. 

Description : The DSMQ module returns the amount of free storage available to the 

user. If the storage area specified is locked against consolidation, the length returned 
is the length of the largest free block available. If the storage area is not locked 
against consolidation, DSMQ will consolidate the free storage and return the length of the 
resulting free block. 

Error Conditions : DSMQ aborts with a message if the storage type is invalid. 

3. 7. 3.8 DSMR - Release Dynamic Storage 

Purpose : To release dynamic storage previously initialized via DSMI . 

Format : CALL DSMR(USER, TYPE) 

Arguments : 

USER - one to six-character name of user releasing dynamic storage. 

TYPE - three-character code indicating dynamic storage type ( 3HGDS or 3HLDS ) . 

Description : The DSMR module releases dynamic storage previously initialized via the 

DSMI module. The user must call DSMR to release Local Dynamic Storage before a new over- 
lay segment is introduced and control passes to another user. 
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Users are not prevented from releasing Global Dynamic Storage, but unpredictable 
results are certain to occur since the ANOPP system uses GDS for its directories and 
tables . 

Releasing a storage area causes the user lock against consolidation to be cleared. 

Error Conditions : DSMR aborts with a message if the user does not own the area of 

storage being released or if the storage type is invalid. 


3. 7. 3. 9 DSMS - Swap IDX Variables 

Purpose : To change the address of an IDX maintained by Dynamic Storage Management 

System to another address. 

Format : CALL DSMS(USER, TYPE, 0IDX, NIDX) 

Arguments : 

USER - one to six-character name of user swapping IDX variables. 

TYPE - three-character code indicating dynamic storage type (3HGDS or 3HLDS). 

0IDX - ( "old IDX”) the IDX variable that is currently defined to Dynamic Storage 

Management System as having the index relative to /XAN0PP/ of the reserved 
block. 

NIDX - ("new IDX”) the IDX variable that, on output from DSMS, contains the 
index value originally contained in the 0IDX parameter. 

Description : The DSMS module may be used when the user wishes to redefine an IDX 

variable. DSMS sets the new IDX variable NIDX to the value of the old IDX variable 0IDX. 

In addition, word 3 of the reserved block control words is redefined to contain the address 
relative to /XAN0PP/ of the new IDX variable. Therefore, in subsequent DSM operations 
where the reserved block is relocated due to free storage consolidation the new IDX 
variable will be updated to contain the new location of the reserved block. 

Error Conditions : DSMS aborts with a message if the storage type is invalid, if the 

user is invalid, or if the IDX is invalid for the reserved block. 
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3.7.3.10 DSMU - Unlock Dynamic Storage 

Purpose : To unlock dynamic storage to permit consolidation of free storage. 

Format : CALL DSMU(USER, TYPE) 

Arguments : 

USER - one to six-character name of user imposing lock against consolidation. 

TYPE - three-character code indicating storage type ( 3HGDS or 3HLDS) . 

Description : Each time DSMU is called the user lock on the storage type specified 

is decremented by one. Therefore, if DSML has previously been called more than one time 
to increment the lock, a single call to DSMU does not insure that the user lock against 
consolidation of free storage is cleared. 

Error Conditions : DSMU aborts with a message if the storage type is invalid or if it 

is already unlocked. 

3.7.3.11 DSMX - Expand a Reserved Block 

Purpose : To expand the size of a reserved block, if a free block of the required 
size is below and adjacent , or if there is an available free block in the free storage 
chain that will satisfy the increased size of the expanded block. 

Format; CALL DSMX(USER, TYPE, IDX, MINI, MAXI, LEN) 

Arguments : 

USER 

TYPE 

IDX 

MINI 

MAXI 


- one to six-character name of user requesting expansion. 

- three-character code indicating storage area where block resides ( 3HGDS 
or 3HLDS) . 

- address relative to /XAN0PP/ of block to be expanded. 

- minimum increment of additional storage required by user (must be greater 
than zero). 

- maximum increment of additional storage required by user (must be greater 
than or equal to MINI). 
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LEN - (OUTPUT) new length of reserved block after expansion. This parameter 
Is set to zero if expansion was not accomplished. 

Description : The DSMX module is called to increase the size of a reserved block 

previously reserved via the DSMG module. If there is a free block adjacent and immediately 
following the reserved block, then the free block is examined for the minimum /maximum 
increment. If the free block satisfies minimum or maximum increment, or a value between 
the two, then the reserved block is expanded into the free block below. 

If all of the free block below is required to expand the reserved block, then the 
free block is removed from the free storage chain and the reserved block trailer word is 
moved to account for the increased size of the block. In addition, the reserved block 
size contained in the header and trailer control words is incremented appropriately. 

If only a portion of the free block below the reserved block is required for ex- 
pansion, then the free block is reduced in size but remains in the free storage chain. 

Control words for the expanded reserved block and the reduced free block are adjusted 

accordingly. In addition, forward and backward pointers in the free storage chain are 
adjusted according to the new start location of the free block. 

If there is no free block following the reserved block, or if the free block below 
and adjacent is insufficient to satisfy either minimum or maximum increment, then the 
storage area is searched for a free block sufficient in size to hold the expanded reserve 
block. If such a free block is found to satisfy minimum or maximum or a value between the 
two, then the reserved block is relocated and expanded into the free block. The space 

allocated for the original reserved block is then freed via DSMF . The index contained in 

the user’s IDX variable is adjusted to reflect the reserved block’s new location. 

If all attempts to expand the reserved block should fail, then the length parameter 
LEN is set to zero. Otherwise, on return from DSMX, the LEN parameter contains the new 
expanded size of the reserved block. 

Error Conditions : DSMX aborts with a message if the minimum increment exceeds the 

maximum increment, or if either the minimum or maximum increment is negative or zero. 
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3.7.4 Auxiliary Modules 

A DSM error processor may be called by any one of the DSM modules if an error condi- 
tion is encountered during its execution. 

3.7. 4.1 DSM Error Message Writer (DSMERR) 

Subroutine DSMERR (NUM, IVAL1, IVAL2 ) processes fatal and non-fatal DSM errors. NUM, 
the integer number of the error message to be printed, is negative if the error is fatal 
and positive if the error is non-fatal. DSMERR prints the informative error message 
(indicated by the absolute value of NUM) with the specific value(s) causing the error 
condition (indicated by the input values IVAL1, IVAL2). If the error is fatal, ANOPP is 
aborted by a call to XEXIT. If the error is non-fatal, a traceback is performed to the 
user callable DSM module that was active when DSMERR was called. 

3.7.5 Hierarchy Charts 

A hierarchy chart is a graphical representation of the logical relationships between 
modules. Figures 1-9 are the hierarchy charts for the DSM modules and the auxiliary 
module. 

In general, only DSM modules appear as a block entity in the charts and all DSM 
modules appear at least once. The charts are in alphabetical order with respect to 
module name except for Figure 1 which represents the logical grouping of the DSM modules. 
A hierarchy chart for the auxiliary is also among the alphabetized charts. 

A module which is not part of DSM but is called by a DSM module is not shown as a 
block entity, but is listed at the bottom of the chart. The module may be an ANOPP 
executive module which is a General Utility or a subprogram provided by one of the CDC 
operating system libraries. In either case, the module is of a utility nature and may be 
called many times by various DSM modules. 
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Symbols and headings used in the hierarchy charts are listed below: 


NAME 

purpose 


NAME 


I 

! 

I 


NAME - module name 
purpose - brief description 


Represents logical module not existing as 
entity. It is used for logical grouping. 


indicates lower level module is called by 
higher level module. 


implies logical group with no direct 
relationship 


in upper right corner of module block 
indicates module is expanded as a separate 
hierarchy. 


ANOPF Modules Called: 


a list of General Utility Modules called 
by the module in this figure. 


CDC System Library Subprograms Called: 


a list of subprograms called by the module 
in the figure and which are not part of 
ANOPP but are provided by CDC NOS operating 
system libraries. 
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Figure 1. Dynamic Storage Management System Hierarchy Chart 
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Figure 2. DSMERR Hierarchy Chart 
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Figure 3, DSMF Hierarchy Chart 
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Figure 4. DSMG Hierarchy Chart 
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Figure 5. DSMI Hierarchy Chart 
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Figure 6. DSML Hierarchy Chart 
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Figure 7. DSMQ Hierarchy Chart 
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Figure 8. DSMS Hierarchy Chart 
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Figure 9. DSMX Hierarchy Chart 
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3 . 8 UPDATE 


3.8.1 Overview 


The ANOPP UPDATE processing phase is invoked by module XCSP during the Control State- 
ment Processing Phase (Section 3.5) when an UPDATE Control Statement (CS) is encountered 
in the primary or secondary input stream. The UPDATE processor provides a method of 
building the members of a data unit by revising existing members of other data units or by 
creating new members. The UPDATE CS provides information about the data unit to be changed 
( 0LDU , if applicable), the data unit to be written (MEW), the source of the UPDATE direc- 
tives (SOURCE), and other processing information. UPDATE directives may reside on an 
existing user data unit/data member (S0URCE = DU ( DM ) on the UPDATE CS), in card image 
format or they may follow the UPDATE CS in the primary input stream (S0URCE = * on the 
UPDATE CS). If the directives follow in the input stream, they are placed on a Uxxx 
member (Section 3.4.5) on the EM system scratch unit XSUNIT by module XRT during the 
primary edit phase. The UPDATE processor determines where the directives reside (user 
member or Uxxx member) and processes them in two major phases, the editing and reformat- 


ting phase and the execution phase , 


In the editing and reformatting phase, records are read sequentially from the data 
member defined by S0URCE until a directive is complete (a $ encountered). The entire set 
of directives is edited, although reformatting ceases when an error is encountered. The 


steps in editing and reformatting a directive are as follows 


4. 


The directive is "cracked" by the XCR module to produce a table which includes 
every field comprising the directive preceded by an integer type code. 

The cracked directive is then checked for syntax. If no syntactical errors 
are found, the card image(s) comprising the directive, tog^her with the 
cracked directive table, is written as one record (a reformatted dire 
onto the EM scratch unit XSUNIT, data member UPDATS. 

If the directive is followed by data records ( i . e . , -ADDR 0LDM=* INSERT 
FR0M=*), the data records are copied, in card image format, onto the data 
unit XSUNIT, data member UPDATS, followed by a null record written to that 

member. 

If the directive is the last record level directive in a set of record level 
directives , a null record is written following the reformatted record level 
directive on data unit XSUNIT, data member UPDATS. 
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EM system control is returned to the module XCSP with the EM system logical error 
flag, NERR, set to .TRUE, if errors are encountered during this phase. 

If no errors are encountered during the editing and reformatting phase , then the 
execution of the directives phase is invoked. In this phase, the UPDATE module, XUP, 
sequentially accesses the reformatted directives from data unit XSUNIT, data member UPDATS, 
and processes them in a single pass performing the functions indicated by each directive. 

When either the last directive has been processed or a processing error is encountered, 
control is returned to the module, XCSP, with NERR set accordingly, and the control state- 
ment processing phase continues. 

3.8.2 Control Statement 

Purpose : The UPDATE Control Statement (CS) provides a means of building a data unit 

by using an existing data unit as a basis for modifications or by adding members from 
various sources with no one data unit as a basis or a combination of both. There are two 
UPDATE modes, Revise and Create, depending on the presence of a data unit as a basis. 

The UPDATE CS, present in the primary or Secondary Input Stream, supplies required 
information for the subsequent processing and allows for selection of various options 
available to the user. The building of the new data unit is controlled by a set of UPDATE 
directives which may either immediately follow the UPDATE CS in the Primary Input Stream 
(Secondary Input Stream prohibited) or be contained in card image record format on a data 
member. 

There are two types of UPDATE directives, member level and record level. Member 
level directives reference a data member to be processed and include -C0PY, -0MIT, -ADDR, 
and -CHANGE. Record level directives must follow a member level -CHANGE directive and 
reference a particular record(s) to be processed. Record level directives include 
-INSERT, -DELETE, and -QUIT. 

The Revise UPDATE mode is invoked when an existing data unit is to provide a basis 
for modification. The 0LDU parameter on the UPDATE CS specifies the basis data unit. 
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The -C0PY and -0MIT directives are valid only during Revise mode and they reference data 
members on the 0LDU data unit. All other directives are also valid during a Revise mode 
UPDATE . 

The Create UPDATE mode is invoked when there is no existing data unit to provide a 
primary basis for modification. The 0LDU parameter on the UPDATE CS is omitted. All data 
members to be written to the new data unit (with or without modification) will come from 
various data units known to the ANOPP run. The -0MIT and -C0PY directives are invalid. 

The -ADDR and -CHANGE directives are valid. 

No data unit utilized by UPDATE (except the new data unit being built) is altered as 
a result of the UPDATE process. The data members residing on the units are sources of 
reference only. However the new data unit is always altered as a result of UPDATE. At 
the start of UPDATE processing the new data unit is "wiped clean" of any members which 
currently reside on the unit (unless the unit has been write-protected via an ARCHIVE CS 
in which case an error condition is invoked and UPDATE in inhibited). 

Format : 

|labelj UPDATE JflLDU = du^ NPWU = du 2# [ ALL ] 

label - (optional) label name 

0LDU clause - (optional) the presence of the 0LDU clause indicates a Revise mode 
UPDATE. The data unit name specified by du^ will be used as the basis for 
UPDATE processing. Member level and record level directives which allow a 
default of 0LDU data unit or imply the 0LDU data unit, will use du^, as the 
required unit. The omission of the 0LDU clause indicates a Create mode UPDATE. 
Defaults or implications of an 0LDU data unit on all directives are invalid in 

Create mode. 

NEWU clause - du 2 is the name of the data unit to be built during UPDATE processing. 
It must be known to Member Manager (see Create and Attach CS) and must not be 


S0URCE = {du 3 (dm 3 )} 


LIST = 


H 
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write-protected (see ARCHIVE CS). All members existing on du^ will be erased 
(i.e., du^ will be wiped clean) as if the du^ had been created via the CREATE 
CS. 

ALL - (optional) if present, indicates a full update of the basis data unit (0LDU 

parameter) is to be performed. All data members on the 0LDU data unit which are 
not processed by a member level directive will be copied to the NEWU data unit. 

A member will not be copied by ALL if the member name is the same as any of the 
following : 

1. The dm name specifying a member on 0LDU in the 0LDM clause of the 
-ADDR or -CHANGE directive. 

2. The ndm name on the -ADD or -CHANGE directive (either explicitly stated 
via the NEWM clause or implied by its omission). 

3. A dm name on the -C0PY or -0MIT directive. 

If ALL is omitted the full update will not be performed for a Revise mode UPDATE. 

The ALL field has no meaning on a Create mode UPDATE. 

S0URCE clause - the S0URCE clause specifies where the set of UPDATE input directives 
will be found. * indicates the directives immediately follow in the Primary 
Input Stream. The use of * is not valid if the UPDATE CS appears in a Secondary 
Input Stream (i.e., processed as a result of a CALL CS). The set of UPDATE 
directives are terminated by an END* CS. 

du 3 (dm^) - specifies the data unit and member containing the directives. dm 3 must 
contain card image records with 10 A8 format (dm^ may have been built previously 
via a DATA CS). 

LIST clause - (optional) if present, the LIST clause specifies the type of printed 
output required from the UPDATE processing. 

The list following the = is a sequence of letters specifying the sections of 
output desired. The list may be a combination of the following: 

E - Directive Echo Section 
S - Summary Section 
C - CHANGE Members Section 
A - ADDR Members Section 
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An additional Header Section is automatically selected. The printed output for 
the various sections is described in Section 3.8.6, 

If the LIST clause is omitted only the Header Section is selected. 

Examples : 

LABI UPDATE NEWU = U1 , SOURCE = LIST = S $ 

(directive set) 

END* $ 

UPDATE 0LDU = U001, NEWU = U002, ALL, S0URCE = DU5(Ml), LIST - SEA $ 

UPDATE 0LDU = U002, NEWU = ABC, S0URCE = *' f $ 

(directive set) 

END* $ 

3.8.3 Member Level Directives 

3. 8.3.1 General Format 

The format of a member level directive is shown below: 

directivename field ffield . . ] $ 

The directivename is -ADDR, -C0PY , -MIT, or -CHANGE. A blank separates directivename 
from the fields which are dependent upon the particular directivename. Fields are sepa- 
rated by a delimiter and may be continued just as in the Control Statement format. The 
delimiters are the same as those for control statements. 

3. 8. 3. 2 -ADDR 

Purpose : To add to the NEWU data unit a data member which is found on the 0LDU unit 

on a unit other than 0LDU, or on card images in the Primary Input Stream. There are two 

formats : 

Format 1 : 

-ADDR 0LDM =*, NEWM = ndm [,F0RMAT = format] [,MNR=n] $ 

OLDM clause - * indicates the member to be added is in card images immediately 
following the -ADDR directive. It is terminated when another member level 


3.8-5 


EXECUTIVE MODULES 


directive is encountered. If the format specified or implied in the F0RMAT 
clause is not Cl then a $ must terminate each record and the next record must 
start on the next card (i.e. , characters following the $ on a card are comment). 
The $ is not considered part of the record. If the F0RMAT clause is omitted or 
specified as Cl, then each record will consist of one card image (10A8) and a $ 
is not required for record termination. 

NEWM clause - ndm specifies the name of the data member added to the NEWU data unit. 
It must not be the name of a member on NEWU as a result of a previous directive. 

F0RMAT clause - (optional) indicates the format of the member, ndm. Format may be 
one of three forms : 

1. 0 - indicates unformatted. 

The characters on the card(s) will be interpreted and converted as 
types I, RS, RD, CS, CD, L, and a Hollerith string of type A„ The 
converted fields will be written to member ndm as unformatted. 

2. nHc^...c n ^ - indicates fixed or variable length format. 

The character string (c,...c .) describe the format of the records to be 

1 n-1 

written to ndm. The fields on the cards will be interpreted and converted 
as types I, RS, RD, CS, CD, L and Hollerith character string type A^. The 
correspondence between the type field specified on the format and the card 
image field is given below. The card image fields are as described for all 
Control Statements. 

format description card image number words written 

code field (S) to record 


I 

integer 

I 

1 

RS 

real single 
precision 

RS 

1 

RD 

real double 
precision 

RD 

2 

CS 

complex single 
precision 

two successive 
RS fields 

2 

CD 

complex double 
precision 

two successive 
RD fields 

4 
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Each element code is separated by a comma. A multiplier may optionally 
precede parentheses enclosing a single element or a group of elements. The 
multiplier specifies the number of times the element(s) are to be repeated. 
The character * may be used as an indefinite multiplier when preceding the 
last element ( s ) of the format. The * specifies an indefinite repeat of the 
element group. 

A fixed length format results when the format does not contain the 
indefinite multiplier ( * ) . Each record will be of the same length de- 
termined by the format. A variable length format results when the format 
includes the indefinite multiplier (*). The records are variable length 
depending on the number of elements written which may or may not include 
the indefinite repeat group in whole or in part. 

3. 2HCI - indicates the card images following should not be interpreted and 
converted but instead written directly to member ndm, which will have a 
card image format. 

The formats resulting from 0 or nH or 2HCI are identical 

to Member Manager (MM) formats (except MM requires a terminating $) and the 
sections describing MM should be referenced for further description. If 
the F0RMAT clause is omitted, then F0RMAT = 2HCI is assumed. 

MNR clause - (optional) indicates the maximum number of records that ndm may contain, 
n is an integer specification. 

If the clause is omitted, the executive system default for Member Manager is 
used (10,000 currently). 

Example 1 : 

-ADDR 0LDM = *, h'EWK = Ml, MNR = 3 $ 

RECORD 1 WILL BE THIS CARD 
RECORD 2 WILL BE THIS CARD 
RECORD 3 WILL BE THIS CARD 
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- (next directive) 

Result: Member Ml has Cl format and contains three records. 

Example 2 : 

-ADDR 0LDM = *, NEWM = M2, F0RMAT = 20HI , 2RS ,A9 ,RD ,CS ,L ,CD$ , MNR = 2 $ 

I 1.5 2E+01 9HABCDEFGHI 3D-01 1.5 2.0 

.TRUE. . 5D+00 - . 841D-06 $ 

II .5 - . 696E-110 9H1234567Q9 10.5D+01 

. 696E+29 . 32E+31 .FALSE. .919D+01 . 210D+06 $ 

- (next directive) 

Result: Member M2 has fixed format ( I ,2RS,A9 ,RD,CS,L,CD) and contains two 

records of length 14. 

Example 3: 

-ADDR 0LDM = *, NEWM = M3, F0RMAT = 0 $ 

.693 $ 

. 70D+01 . 898D+20 .TRUE. 3HABC $ 

10 20 30 $ 

- (next directive) 

Result: Member M3 is unformatted and can have a maximum of 10,000 records but actually 

contains three records as follows : 

Record 1 is 1 word long (one floating point RS) 

Record 2 is 6 words long (two floating point type RD, a logical .TRUE., one 
word containing string ABC left justified and blank filled) 

Record 3 is 3 words long (three integers type I) 

Format 2 : 

-ADDR 0LDM =j^ (dm) | ,NEWM=ndm $ 

0LDM clause - indicates where the member to be added is found, du(dm) specifies the 
unit and member name, du may or may not be the name of the unit named as the 
0LDU unit on the UPDATE CS. If du is omitted, the unit named as 0LDU is assumed. 
The new ndm member will be identical to the member named in the S0URCE clause, 
dm and ndm may or may not be the same name. 
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NEWM clause - (optional) ndm is the name of the data member added to the NEWU. If 

the clause is omitted the name dm specified in the 0LDM clause is used for ndm. 

Examples : 

-ADDR 0LDK = UNIT1 (KEMA), NEWM=M1 $ 

-A DDR 0LDM = MEM5 , NEWM=MZ $ 

-ADDR 0LDM = M3 $ 

3. 8. 3. 3 -C0PY 

Purpose : To copy to the N'EWU data unit one or several data members on the 0LDU data 

unit . 

Format : 

-C0PY dm [ ,dm . . *] $ 

dm - name of the data member residing on 0LDU to be copied to NEWU. dm must not be 
the name of a member already written to NEWU as a result of a previous member 

level directive. 

Examples : 

-C0PY ABC, Ml, MEMB, D1 $ 

-C0PY XYZ $ 

3. 8. 3. 4 -0MIT 

Purpose : To omit the copying of one or several data members on the 0LDU data unit to 

the NEWU data unit during processing of the ALL UPDATE CS option. 

Format : 

-0MIT dm [,dm . . .] $ 

dm - name of the data member residing on 0LDU to be omitted as a copy possibility 
during ALL processing. 

Examples : 

-0MIT ABC, MEM1, MEM2, MEM 5 $ 

-0MIT MEM10 $ 
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3.8. 3. 5 -CHANGE 

Purpose : To change a data member on either the 0LDU data unit or another data unit 

via record level directives which follow the -CHANGE directive and to write it on the NEWU 
data unit with rename capability. 

Format : 

-CHANGE 0LDM= | du ^ m) } [,NEWM=ndm] [ ,MNR=n ] $ 

0LDM clause - specifies the data member to be changed. 

du(dm) - specifies the data member to be changed. Data unit du may be the unit 

named as 0LDU on the UPDATE CS. dm with du omitted specifies the data member 
which resides on the 0LDU data unit to be changed. In either case, the data 
member, dm, is referenced on the record level directives as 0LDM. 

NEWM clause - (optional) ndm is the name to be given to the member written to NEWU. 

If the clause is omitted then the name dm specified in the 0LDM clause is used. 

MNR clause - (optional) specifies the maximum number of records the member ndm will 
contain (regardless of the number of records contained on the 0LDM member). If 
omitted, the MNR used in creating jOLDM will be used with a possible increment as 
explained below. 

NRECq = current number records on 0LDM 

MNRq = MNR used when 0LDM was created 

MNR^^ = MNR to be used in creating ndm. 

IF (NREC q < .95 * MNR q ) 

THEN MNR , = MNR A 

ndm 0 

ELSE MNR , s l.l * KNR a 
ndm 0 

Usage : Record level directives immediately follow the -CHANGE directive and direct 

the altering or changing of the 0LDM member. Processing of the -CHANGE terminates when 
either another member level directive or the end of the input set of directives to the 
UPDATE CS is encountered. 
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Examples : 

-CHANGE 0LDM=M1, NEWM=M2 $ 

(record level directives) 

-(Member level directive) 

-CHANGE 0LDM=UN1(KEM),MNR=2OOO $ 

(record level directive) 


3.8.4 Record Level Directives 
3. 8.4.1 General Description 

The format of a record level directive is shown below: 

directivename field £field . ..J ^ 

The directivename is -INSERT, -DELETE, or -QUIT. A blank separates the directivename from 
the fields which are dependent upon the particular directivename. Fields are separated by 
a delimiter and may be continued 3 ^st as in the Control Statement format. De^im^ters are 
the same as for the Control Statement Format. 

Throughout record level directives operands i and j are used as pointers to relative 
record positions in the old member. Record level directives must be processed sequenti- 
ally with respect to i and j. This is necessary because the new member is created in one 
pass. So, a directive referencing records 5 through 8 (i^ through j ^ ) must be called 
before a directive referencing records 9 through 10 (i 2 through j^) and never vice versa. 
The i value (if present) in any directive must be greater than the i (and j if present) 
specified in the preceding directive as noted in each of the following directives. 
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This is accomplished by an old member reference pointer, P, which is initialized to 
zero at the beginning of the CHANGE processing. The i value specified on a record level 
directive must be greater than P. Upon completion of the directive P assumes one of the 
following three values : 

1. the j value (if present) 

2. the i value (j not present, i present) 

3. unchanged (i and j not present) 

The next record level directive must have an i value (if present) greater than the 
new value of P. The i parameter may be omitted on the -INSERT and -QUIT directives as 
described in the following sections. 

The -INSERT, -DELETE, and -QUIT record level directives are processed under control 
of the preceding -CHANGE member level directive. The -CHANGE directive is in control 
until another member level directive or the end of the input SOURCE is encountered. If 
a -QUIT is encountered, processing of the member being CHANGEd is terminated according to 
the -QUIT specifications. If a -QUIT is not present and the -CHANGE is terminated by 
encountering a member level directive or the end of the input stream, then the member 
being CHANGEd is completed as follows. Any records remaining on the old member following 
the reference pointer P will be copied to the new member, (i.e., records P+1 through the 
last record on 0LDM are copied to the new member). The new member is then closed. 

3. 8.4. 2 -INSERT 

Purpose : To insert one or more records into a data member being changed. 

Format : 

-INSERT [i J [fR0M= | 0LDM |] [(m [,n])J $ 

i - the record after which the specified records will be inserted, i must be greater 
than the old member record pointer (P). Records P+1 through and including 
record i will be copied to the new member followed by the inserted records . 

The i may be omitted in which case the records are inserted immediately 
onto the new member and P remains unchanged. Thus records may be inserted at 
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the beginning of the member (when P=0) if -INSERT with I omitted is the first 
directive following the CHANGE. 

FR0M clause - the FR0M clause specifies the source of the records to be inserted. 
FR0M=* indicates the records to be inserted immediately following the INSERT 
directive. FR0M=0LDM indicates the member named as 0LDM on the CHANGE directive 
contains the records to be inserted. The entire FR0M clause may be omitted, in 
which case FR0M=* is assumed. The FR0M=* clause is valid in the Primary or 
Secondary Input Stream. 

If the format of 0LDM is unformatted, fixed, or variable then a $ must terminate 
each input record and the next record must begin on a separate card image. 

(m,n) - specifies which records on the 0LDM are to be inserted. It is ignored if 

FR0M=* is present. Records m through n will be inserted (n> m > 1). n may be 
omitted and, if so, m = n is assumed. The REC0RDS clause may be omitted and if 
so, all of the records on 0LDM will be inserted. Records which follow immedi- 
ately in the input stream are card images. If the format of 0LDM is card image 
( 2HCI used when created via UPDATE ADDR) then each card image is copied directly 
.to ndm as a record. 

After processing an -INSERT, the record pointer in the 0LD member points to 
record i if i is present. If i is not present then the old member record 
pointer is unchanged. 

Example 1: 

Assume N1 is a member on the 0LDU data unit and contains 1000 card images , perhaps 
built via a DATA CS. Then to insert two card images following the sixth record on 
N1 the following is required: 

-CHANGE 0LDM = N1 $ 

-INSERT 6 $ 

(card image) 

(card image) 

-(next member level directive) 


rvr 
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Example 2: 

The following directive copies records 1 through 5 from the old member and inserts 
them after record 6 of the old member. 

-INSERT 6, FR0M=0LDM (1,5) $ 

Example 3 : 

Assume the 0LDU data unit is UNI and contains member MEM which consists of 2000 
records. MEM was created with a maximum record number (MNR) of 2010 records. The 
new member on NEWU is to be named MEMNEW. To copy records 5 through 10 from MEM to 
the beginning of the new member and copy (without altering) the other records in MEM, 
the following sequence may be used. 

-CHANGE 0LDM = MEM, NEWM = MEMNEW, $ 

-INSERT FR0M = 0LDM (5,10) $ 

-(next member level directive) 

Example 4: 

Assume the name as Example 3 except records 5 through 20 are to be inserted. This 
would result in 2016 records on MEMNEW but the automatic expansion algorithm for 
MNR is sufficient therefore the following is used: 

-CHANGE 0LDM = MEM, NEWM = MEMNEW $ 

-INSERT FR0M = 0LDM (5,20) $ 

-(next member level directive) 

Example 5 : 

Assume the same as Example 3 except records 5 through 205 are to be inserted. 

The automatic expansion algorithm will result in 2100 which is insufficient for 
the MEMNEW of 2201 records. Therefore MNR must be specified. 

-CHANGE 0LDM = MEM, NEWM = MEMNEW, MNR = 2500 $ 
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3. 8. 4. 3 -DELETE 


Purpose: To delete records on the member being changed. 

Format : 

-DELETE i [,j] $ 

i 4 j _ i and j specify the range of records to be deleted (P— i — j) where P is 

the old member record pointer. Records P+1 thru i-1 (p^ i) on 0LDM are copied 
to the new member. The records i thru j are effectively deleted by setting P to 
the value of j . 

j may be omitted which results in the one record i being deleted (same 
as i = j ) . 


Example : 

At initialization record pointer P set 
to zero. (P=0) 

Records 1,2,3 copied to new member; 4,5,6 
skipped. (P=6) 

-INSERT FR0M=0LDM (12,13) $ Records 12 and 13 are copied from old member 

onto new member after current position of 
P which is 6. (P unchanged) 

-DELETE 9 10 Records 7 and 8 are copied from old member 

to new member; 9,10 skipped. (P=10) 

Old Membe r New Member 

Rec 1 
Rec 2 
Rec 3 
Rec 4 
Rec 5 
Rec 6 
Rec 7 
Rec 8 
Rec 9 
Rec 10 
Rec 11 
Rec 12 
Rec 13 
Rec 14 


Rec 1 
Rec 2 
Rec 3 
Rec 12 
Rec 13 
Rec 7 
Rec 8 


-CHANGE 0LDM = JET $ 
-DELETE 4,6 $ 
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3. 8. 4. 4 -QUIT 

Purpose : To terminate processing of the member being altered via the -CHANGE direc- 

tive after a specified record. 

Format : 

-QUIT [i] $ 

i - (optional) specifies the record with which to terminate processing. All records 
from the current position of the record pointer plus one through record i are 
copied onto the new member. Record i will be the last record copied to the new 
member. 

If i is omitted processing on the new member is terminated immediately. 

The -QUIT directive, if present, must be the last record level directive under 
the control of the -CHANGE directive. 


3.8.5 Format Summary 

The following is a summary list of valid formats for the UPDATE CS and the UPDATE 
Member level and Record level directives: 


UPDATE CS 


Member Level Directives 


(du(dm)i 


-ADDR 

0LDM=(dm ) 

-C0PY 

dm J^diti . . /J $ 

-0MIT 

dm $ 

-CHANGE 0LDM=|^ <dn,) | 


NEWU = du 

2' [ ALL ’] 

SOURCE =|* u (dm 3 )| [lIST= x 

£,F0RMAT= • 

2HCI$ > J 

£ ,MNR=nJ $ 

M=ndm] $ 




£,NEWM=ndmJ £,MNR=nJ $ 
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Record Level Directives 


-INSERT [i] [f R 0M={“ ldm }] [( m ,n)] $ 

-DELETE i [»j ] $ 

-QUIT [i] $ 

3.8.6 UPDATE Output Description 

3. 8. 6.1 HEADER SECTION 

UPDATE PROCESSING BEGINNING WITH THE FOLLOWING PARAMETERS 


CREATE 

REVISE 


MODE 


New Data Unit = NAME (A8) Old Data Unit = NAME (A8) 


SOURCE OF UPDATED DIRECTIVES IS 


PRIMARY INPUT STREAM LIST = S E A C 

DATA UNIT NAME (AB), DATA MEMBER NAME (A8) 


3. 8. 6. 2 DIRECTIVE ECHO SECTION 


(all card image directives on S0URCE data member or * are listed in 10A8 format) 


EDITED CARD IMAGE 


NOTE - entire Directive Echo is printed prior to any processing. 
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3. 8. 6. 3 SUMMARY SECTION 


UPDATE PROCESSING SUMMARY 
NEW DATA UNIT = NAME (A8) 


MEMBER 

NUMBER OF 

RECORD TYPE 

MAXIMUM 

RESULT 

NAME 

RECORDS 


LENGTH 


Name ( A8 ) 

(13) 

Cl 

(114) j 

f -ADDR 


I -CHANGE 
-C0PY 
-ALL 

TOTAL OF (15) MEMBERS ON NEW DATA UNIT 


3. 8. 6. 4 CHANGE MEMBER SECTION 

DATA UNIT = NAME (A8) DATA MEMBER = NAME (A8) FORMAT = 

RECORD 

1 card image record (10A8) if Cl 

OR 

octal record (5023) multiple 


j FORMAT IMAGE ) 
j UNFORMATTED j 


n 

(17) one line of (10A8) or multiple lines of 5023. 


NOTE: The member written to the new unit is listed upon completion of the CHANGE Directive. 
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3. 8. 6. 5 ADDR MEMBER SECTION 

I 

DATA UNIT = NAME (A8) DATA MEMBER = NAME (A8) FORMAT - j 

RECORD 

1 card image record (10A8) if Cl 

OR 

octal record (5023) multiple print lines 


n 

(17) one line (10A8) or multiple lines (5023) 


NOTE: The member is listed upon completion of the ADDR Directive. 


FORMAT IMAGE 
UNFORMATTED 
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3.8.7 Error Philosophy 

The set of UPDATE member level directives, contained either on the SOURCE data member 
or in the Primary Input Stream, is executed sequentially beginning with the first direc- 
tive. If no error occurs in the sequential processing, UPDATE terminates normally when 
execution of the last member level directive in the directive set is complete. However, 
if an error is encountered while processing any member level directive or any record level 
directive under the control of a member level directive (i.e., -CHANGE), then further 
UPDATE processing is inhibited and UPDATE is terminated. 

Upon UPDATE error termination the NEWU unit contains all members written as a result 
of the previous member level directive which executed successfully. If the error occurred 
during execution of a record level directive and the member has been partially written as 
a result of immediately preceding successful record level directives then the partially 
complete member is considered complete and will be present on NEWU. A partially complete 
member is the result of the -CHANGE directive being terminated by a record level directive 
error. The contents of the NEWU unit will be reflected in the summary section which is 
printed upon error termination if selected via the LIST field on the UPDATE CS. 

Errors may be detected in UPDATE processing during one of two phases , the edit phase 
or the execution phase. 

During the edit phase, the set of UPDATE member level or record level directives 
contained either on the S0URCE data member or in the Primary Input Stream is edited for 
syntactical errors. The directives are read and checked sequentially, beginning with the 
first directive in the set. If a directive is syntactically correct, it is then stored in 
an executable format, known internally to UPDATE. If no error is detected on any UPDATE 
directive during the edit phase, the entire reformatted set of directives will be input to 
the execution phase. 

If an error is detected on an UPDATE directive during the edit phase, the remainder 
of the directives in the set will be checked for syntax, but will not be reformatted for 
execution. The directive(s) in error will be printed, and UPDATE will terminate following 
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the edit phase if any error in syntax is present in the set of directives. The following 
errors include conditions which would result in an edit phase error and inhibition of 
execution processing. 

1. Required field missing - for example, the 0LDM clause is not present on an 
-ADDR directive. 

2. Invalid field type - for example, on the -ADDR directive the F0RMAT clause is 
present and contains F0RMAT = 10A8. 

3. Incomplete directive - for example, -0MIT $ which contains no dm fields. 

This is similar to required field missing. 

4. Invalid directive name - for example, a mispunch resulted in the directive 
-C0PI DM $. 

During the execution phase, the reformatted set of syntactically correct UPDATE 
directives are executed sequentially beginning with the first directive. If no error 
occurs in the sequential processing, UPDATE terminates normally when execution of the 
member level directive in the directive set is complete. However, if an error is en- 
countered while processing any member level directive or any record level directive under 
the control of a member level directive (i.e., -CHANGE) then further UPDATE processing is 
inhibited and UPDATE is terminated. 

Upon UPDATE error termination the NEWU unit contains all members written as a result 
of the previous member level directive which executed successfully. If the error occurred 
during execution of a record level directive and the member has been partially written as 
a result of immediately preceding successful record level directives, then the partially 
complete member is considered complete and will be present on NEWU. A partially complete 
member is the result of the -CHANGE directive being terminated by a record level directive 
error. The contents of the NEWU unit will be reflected in the summary section which is 
printed upon error termination if selected via the LIST field on the UPDATE CS. 

The types of errors which may cause UPDATE error termination are varied. Some error 
types are specific to a particular directive being executed while other error types are 
general and apply to all directives. Directive errors are implied by the requirements for 
each particular directive. The general errors include duplicate member attempted on 
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NEWU. This error is emphasized and provides the basis for handling conflicting direc- 
tives. The general conflict rule for executing successfully the set of UPDATE directive 
is as follows: "there shall not be an attempt to write on the NEWU unit a data member 

which has the same name as a data member previously written on the NEWU." There is no 
restriction as to how many times a particular du(dm) may be used on the various directives 
as long as the resulting member to be written on the NEWU is not the name of a member 
already residing on the NEWU. UPDATE will not attempt to overwrite members on NEWU. Since 
NEWU either contains no members upon entry to the UPDATE CS processing phase or is "wiped 
clean" before UPDATE directive processing begins, the conflict rule is violated only by an 
incompatible set of directives and not because of the contents of NEWU upon entry to 
UPDATE processing. The following directive sequence is compatible since the -0MIT directive 
does not result in a member being written to NEWU. The -0MIT directive has no meaning, 
however since the -ADDR directive would eliminate the possibility of DM2 (if present on 
the designated 0LDU) being written to the NEWU during ALL processing. 

-0MIT DM2 $ 

-ADDR S0URCE = *, NEWM = DM2 $ 

Also compatible is the following sequence: 

-0MIT DM1 $ 

-C0PY DM1, DM3 $ 

-0MIT DM3 $ 

-ADDR S0URCE = DM6, NEWM = DM7 $ 

-C0PY DM6 $ 

-CHANGE 0LDM = DM6, NEWM = DMB $ 

The following sequence results in a conflict error: 

-CHANGE 0LDM = DM3, NEWM = DM10 
-C0PY DM10 $ 
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3.8.8 Auxiliary Module 

An auxiliary module performs a function common to UPDATE modules and is available for 
use only by UPDATE modules. 

3. 8. 8.1 UPDATE Error Message Writer (XUPERR) 

Subroutine XUPERR (NM, CNAME, VAR1, VAR2) processes fatal and non-fatal errors for 
the UPDATE modules. NM, the integer number of the error message to be printed is negative 
if the error is fatal and positive if the error is non-fatal. XUPERR prints the informa- 
tive error message indicated by the absolute value of NM with the name of the calling 
module ( CNAME ) and specific value(s) involved in the error condition (VAR1, VAR2 ) . If the 
error is fatal, ANOPP is aborted by a call to XEXIT. 

3.8.9 Hierarchy Charts 

A hierarchy chart is a graphical representation of the logical relationship between 
modules. Figures 1 through 6 are the hierarchy charts for UPDATE. 

In general, only UPDATE modules appear as a block entity in the charts and all UPDATE 
modules appear at least once. A module which is not part of UPDATE but is called by an 
UPDATE module is not shown as a block entity but is listed at the bottom of the chart . 

The module will be an ANOPP executive module which is part of the Data Base Management 
System (DBM), the Dynamic Storage Management System (DSM) , or the General Utilities, is of 
a service or utility nature, and may be called many times by various UPDATE modules. 

Symbols and headings used in the hierarchy charts are given below: 

NAME - module name 
purpose - brief description 


indicates lower module is called by the 
higher module. 


in upper right corner of module block indicates 
module is expanded as a separate hierarchy. 


NAME 

purpose 
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ANOPP Modules Called: a list of DBM, D6M , and General Utility 

modules called by the modules in this figure. 


CDC System Library Subprograms Called: list of subprograms called by the module 

in the figure and which are not part of 
ANOPP but are provided by CDC NOS operating 
system libraries. 
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Figure 3. XUPERR Hierarchy Chart 




EXECUTIVE MODULES 



W 

55 

M 

CM 

X 


o 

X 


X 

oo 

X 

0) 

H •* 
H X 

m h 

O D 
Cm 

co S 
4) £ 


3 

TJ 


0 m 

Pm 

O 


X 

H 

W 

a 

ac 

sn 


3.8-28 


Figure 4. XUPINS Hierarchy Chart 
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Figure 6. XUPXFR Hierarchy Chart 
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3.9 GENERAL UTILITIES 

3.9.1 Overview 

General Utilities are general purpose subprograms available to all executive system 
modules. Some resulted during executive system development from the recognition of 
functions common to several modules. Others are required to replace CDC Fortran intrinsic 
functions which are NON-ANSI. Most of these utilities are available for use by functional 
modules. A few subprograms, classed as utilities but not available to the functional 
modules, are specific to executive system philosophy and design criteria and do not 
provide the functional module with increased capability. 

3.9.2 Reference List 

3. 9. 2.1 ALPHA 

Subprogram Type : Logical Function 

Calling Sequence : ALPHA(CHAR) 

Purpose : Return a function value of .TRUE, if input character, CHAR, is alphabetic. 

Otherwise, return a function value of .FALSE. 

3. 9. 2. 2 DIGIT 

Subprogram Type : Logical Function 

Calling Sequence : DIGIT(CHAR) 

Purpose : Return a function value of .TRUE, if the input character, CHAR, is alpha- 

betic. Otherwise, return a function value of .FALSE. . 

3. 9. 2. 3 D VALUE 

Subprogram Type : Double Precision Function 

Calling Sequence : DVALUE(RS) 

Purpose : Enable the use of any mode variable, RS, as if it were double precision 

with no conversion. 
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3.9. 2.4 I AND 


Subprogram Type : Integer Function 

Calling Sequence : IAND(I,J) 

Purpose : Perform logical product of the two input words I and J. 

3.9. 2.5 ICD 


Subprogram Type : Integer Function 

Calling Sequence : ICD(I) 

Purpose : Return the integer value which corresponds to the input character I, a 

valid numeric character (Al) in the range 0-9. 


3.9. 2.6 ICI 


Subprogram Type : Integer Function 

Calling Sequence : IC 1(1) 

Purpose : Return the numeric character (Al) which corresponds to the input variable 

I, a valid integer in the range 0-9. 

3. 9. 2. 7 ICOMPL 

Subprogram Type : Integer Function 

Calling Sequence : ICOMPL(I) 

Purpose : Return the complement of the input variable I . 

3. 9. 2. 8 IDATE 

Subprogram Type : Subroutine 

Calling Sequence : CALL IDATE(D) 

Purpose : In the output variable D, return the current date in the A0 format hM/DD/YY. 
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3. 9. 2. 9 ILOC 

Subprogram Type : Integer Function 

Calling Sequence : ILOC(I) 

Purpose : Return the integer index relative to /XANOPP/ , the dimensional array to 
which all Dynamic Storage addresses are indexed, of input variable I. 

3.9.2.10 ILSHFT 

Subprogram Type : Integer Function 

Calling Sequence : ILSHFT(I,J) 

Purpose : Left shift with zero fill the contents of the input word I by J bits. J 

must have a value in the range 0-number of bits per word. 

3.9.2.11 IMASK 

Subprogram Type : Integer Function 

Calling Sequence : IMASK(I) 

Purpose : Form a mask of I high-order bits. I must have a value in the range 0- 

number of bits per word. 

3.9.2.12 IOR 

Subprogram Type : Integer Function 

Calling; Sequence i I0R(I,J) 

Purpose : Perform a logical sum of the two input words I and J. 

3.9.2.13 IRSHFT 

Subprogram Type : Integer Function 

Calling Sequence : IRSHFT(I,J) 

Purpose : Right shift with zero fill the contents of the input word I by J bits. J 

must have a value in the range 0-number of bits per word. 
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3.9.2.14 ISHIFT 

Subprogram Type : Integer Function 

Calling Sequence : ISHIFT(I*J) 

Purpose : Perform a left circular shift (J.GT.O) or right, end-off, sign extend shift 

(J.LT.O) of the input word I by J bits. The absolute value of J must be less than or 
equal to the number of bits per word. 

3.9.2.15 ITIME 

Subprogram Type : Subroutine 

Calling Sequence : CALL ITIME(T) 

Purpose : In the output variable T, return the time of day in the A8 format hh.mm.ss. 

3.9.2.16 I VALUE 

Subprogram Type : Integer Function 

Calling Sequence : IV ALUE ( I ) 

Purpose : Enable the use of any mode word, I, as if it were an integer with no 

conversion . 

3.9.2.17 IXOR 

Subprogram Type : Integer Function 

Calling Sequence : IXOR(I,J) 

Purpose : Perform an exclusive OR of two input words I and J. 

3.9.2.18 MEMNUM 

Subprogram Type : Integer Function 

Calling Sequence : MEMNUM(IN) 

Purpose : Convert the three numeric characters in the input word IN to an integer 
value in the range 0-999. IN is expected to be in the form Axxx (A4) where A is an 
alphabetic character and xxx are numeric characters in the range 001-999. 
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3.9.2.19 NUMTYP 

Subprogram Type : Integer Function 

Calling Sequence : NUMTYP (NAME) 

Purpose : Return the integer type code corresponding to the input alpha type code for 

an ANOPP data type. For a full description of ANOPP Data Types, see the NDTCL array in 

common block /XCVT/ . 

3.9.2.20 NWDTYP 

Subprogram Type : Integer Function 

Calling Sequence : NWDTYP( ITYPE) 

Purpose : Return the number of words required for an ANOPP data type given the 

integer type code. For a full description of ANOPP Data Types, see the NDTCL array in 

common block /XCVT/ . 

3.9.2.21 RVALUE 

Subprogram Type : Real Function 

Calling Sequence : RVALUE(R) 

Purpose : Enable use of any mode word, R, as single precision without conversion. 

3.9.2.22 XASKP 

Subprogram Type : Subroutine 

Calling Sequence i CALL X AS KP(PNAME, ITYPE) 

Purpose : Determine if the input variable PNAME , (A8), is a current User Parameter, 

and, if it is, return the integer type code of the ANOPP data type in the output variable 
ITYPE. If PNAME is not a current User Parameter, a zero is returned in ITYPE. A User 
Parameter is a numerical, logical, or character string value established in the control 
statement stream by a PARAM CS or in a functional module with XPUTP. This value is main- 
tained throughout ANOPP in the User Parameter Table (UPT) and User String Table (UST) and 

may be changed or retrieved. 
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3.9.2.23 XBSRIN 

Subprogram Type : Subroutine 

Calling Sequence : CALL XBSRIN( JXX , JX ,NEL , INDEX , IFND , IERR ) 

Purpose : Performs a binary search for integer Jxx in array Jx. 

3.9.2.24 XBSRRD 

Subprogram Type : Subroutine 

Calling Sequence : CALL XBSRRD ( DXX , DX , NEL , INDEX , IFND , IERR ) 

Purpose : Performs a binary search for real double DXX in array DX. 

3.9.2.25 XBSRRS 

Subprogram Type : Subroutine 

Calling Sequence : CALL XBSRRS ( RXX , RX , NEL , INDEX , IFND , IERR) 

Purpose : Performs a binary search for real single RXX in array RX. 

3.9.2.26 XCR 

Subprogram Type : Subroutine 

Calling Sequence : CALL XCR( B IN ,NC , OUTBUF , LAVAIL , LUSED , ICONT , NBAD , IERR ,NF ) 

Purpose : XCR is the executive crack module which identifies ANOPP Data Types on a 

card image and converts these fields as required to numerical representations. The 

converted fields are represented in table form via the OUTBUF array. There is one entry 

in OUTBUF per field encountered except for blanks and commas which are recognized as 

delimiters but not entered into the table. The table entries are variable length. The 

first word of each entry contains the integer type code of the ANOPP data type that 

follows. The value length is implied by the type code. Fields recognized by XCR for 

output are Integer, Real Single Precision, Real Double Precision, Hollerith String or 

Alpha, Logical Operator, Name, Type A Delimiter, and Unrecognizable. The integer type 

codes and the corresponding value lengths are found in the ANOPP Data Types Table (array 

NDTCL in common block /XCVT/). The fields as they appear on a card image along with the 

output integer type codes and value lengths required are shown in Table 1. 
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ANOPP DATA 
TYPE 

INTEGER 
TYPE CODE 

CARD IMAGE 
FORM 

OUTBUF ( 

VALUE FORM 

OUTBUF VALUE 
WORD LENGTH 

INTEGER 

a 

NNNN . . . N 
OPTIONAL + - 
.LE. 18 DIGITS 
.LE. ( 2**31 )-l 

BINARY 

INTEGER 

1 

REAL 

SINGLE 

PRECISION 

2 

N. 

N.NN 

N.NN+N N.NN-N 

N.NNEN 

NEN 

NE+N NE-N 
.LE. 14 DIGITS 
.GE. 10** -29 3 
.LE. 10**+322 
OTIONAL + - 

BINARY 

FLOATING 

POINT 

1 

REAL 

DOUBLE 

PRECISION 

3 

N . NNDN 

N.NND+N N.NND-N 
NDN 

ND+N ND-N 
OPTIONAL + - 
.GE. 10**-293 
.LE. 10**+322 

BINARY 

FLOATING 

POINT 

2 

HOLLERITH 

STRING 

-N 

i i 

NHXXX . . .X 
N .LE. 132 

A8 

! (N+7 )/* 

LOGICAL 

6 

.TRUE. .FALSE. 

FORTRAN 

GENERATED 

INTEGER 

1 

ALGEBRAIC 

OPERATOR 

7 

+ 

A1 

1 

LOGICAL 

OPERATOR 

B 

.EQ. .LE. -LT. 

.NE. .GT. .GE. 

A4 

1 

NAME 

9 

. LE 8 ALPHANUMERIC 
CHARACTERS FIRST 
IS ALPHA 

A8 

1 

TYPE A 
DELIMITER 

10 

( ) = / * 

A1 

1 

UNRECOGNIZABLE 

20+N 

NONE OF THE ABOVE 
OR EXCEED RANGE 
N= NUMBER CHARACTERS 
IN FIELD 

A8 

(N+7)/8 


Table 1. Card Images of ANOPP Data Types Recognized by Executive Crack Module XCR 
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Continuation calls to XCR may be used to process multiple card images as if they were 
one contiguous image. In such continuation calls, Hollerith string fields may be continu- 
ed on the subsequent card image, however, other fields may not be continued. 

3.9.2.27 XCRWC 

Subprogram Type : Subroutine 

Calling Sequence : CALL XCRWC(BIN ,NC ,OUTBUF ,LAVAIL,LUSED,ICONT,LCP,IERR,NF) 

Purpose : XCRWC is the executive crack module which identifies fields or multiple 

card images with variable number of columns and cracks those card images without con- 
verting fields. XCRWC builds an output table, OUTBUF, of these fields. There is one 
entry for each field encountered except for blanks and commas which are recognized as 
delimiters but not entered into the table. The table entries are variable length. The 
first word of each entry contains the integer type code of the ANOPP data type that 
follows. The value length is implied by the type code. Fields recognized by XCRWC are 
Hollerith String, Type A Delimiter, and Unrecognizable. The integer type codes and the 
corresponding value lengths are found in the ANOPP Data Type Table (array NDTCL in common 
block /XCVT/ ) . The fields as they appear on a card image along with the output integer 
type codes and value length required are shown in Table 2. Continuation calls to XCRWC 
may be used to process multiple card images as if they were one contiguous image. In such 
continuation calls, Hollerith string fields may be continued on the subsequent card image, 
however, other fields may not be continued. 

3.9.2.28 XEXIT 

Subprogram Type : Subroutine 

Calling Sequence : CALL XEXIT 

Purpose : Abnormally terminates ANOPP when a fatal error has occurred and performs a 

trace back from XEXIT to XM. This utility is not available for use by the functional 
module . 
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ANOPP DATA TYPE 

INTEGER 
TYPE CODE 

CARD IMAGE FORM 

OUTBUF 
VALUE FORM 

OUTBUF VALUE 
WORD LENGTH 

Hollerith String 

-N 

NHxxxx. . .xx 
N. LE. 132 

A8 

(N+7 )/8 

Type A 
Delimiter 

10 

( ) = / * 

A1 

1 

Unrecognizable 

20+N 

None of the above 
or exceed range 
N = number 
characters in field 

A8 

(N+7 )/8 


Table 2. Card Images of ANOPP Data Types Recognized by the 
Executive Crack Module (XCRWC). 
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3.9.2.29 XFAN 

Subprogram Type : Subroutine 

Calling Sequence : CALL XFAN(RNAME ,ANAME) 

Purpose : XFAN returns ANAME (A8) the alternate name for RNAME (A8) retrieved from 

the Alternate Names Table (ANT) or RNAME if the desired entry is not in the ANT. Alter- 
nate names are established in the control statement stream via the EXECUTE CS. This set 
of alternate names, maintained in the ANT, is available only during the execution of the 
functional module. 

3.9.2.30 XFETCH 

Subprogram Type : Subroutine 

Calling Sequence : CALL XFETCH (NAME, VALUE) 

Purpose : Fetch the value of the Executive System Parameter specified by NAME (A8). 

Executive System Parameters currently available for fetching are: 

Valid Name Residence Type Description 

INK /XCVT/ integer write unit for all FORTRAN write 

requests to printer. Used by 
system and functional modules . 


3.9.2.31 XFMT3 

Subprogram Type : Subroutine 

Calling Sequence : CALL XFMTQ(NAME, ITYP) 

Purpose : Returns in ITYP the format type of the member specified by NAME, NAME is 

a three word array where NAME(l) is the Data Unit name (A8), NAME(2 ) is the Data Member 

name (A8), and NAME(3) is to be left unaltered as it is used by Member Manager. Valid 

values of ITYP are: 

Cl - card image format 
F - fixed format 
V - variable format 
U - unformatted 
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3.9.2.32 XGETP 

Subprogram Type : Subroutine 

Calling Sequence : CALL XGETP( PNAME, ITYPE, VALUE) 

Purpose : Retrieves the value of the User Parameter PNAME (A8) having integer type 
code ITYPE from the User Parameter Table (UPT) and User String Table (UST). It is assumed 
that the user has verified that PNAME is in fact an entry in the UPT. A User Parameter is 
a numerical, logical, or character string value established in the control statement 
stream by a param CS or in a functional module with XPUTP . This value is maintained 
throughout ANOPP in the UPT and UST and may be retrieved or changed. 

3.9.2.33 XINC 

Subprogram Type : Logical Function 

Calling Sequence : XINC( IARRAY,RARRAY ,DARRAY ,IFC) 

Purpose : Determines if the input array ( I ARRAY ,RARRAY , or DARRAY), assumed to be in 

monotonic sequence, is increasing. The array used is determined by the integer type code 
specified by IFC. Expected type codes are: 1-Integer, 2-Real Single Precision, or 

3-Real Double Precision. 

3.9.2.34 XMOVE 

Subprogram Type : Subroutine 

Calling Sequence : CALL XMOVE ( FROM , TO, NUM) 

Purpose : Moves NUM entries from sending array FROM to the corresponding position in 

receiving array TO. 

3.9.2.35 XMPRT 

Subprogram Type : Subroutine 

Calling Sequence : CALL XMPRT (NAME) 

Purpose : Prints the Data Member specified by NAME, a three word array where NAME ( 1 ) 

is the Data Unit name (A8), NAME(2) is the Data Member name (A8), and NAME( 3) is to be 

left unaltered as it is used by Member Manager. 
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3.9.2.36 XPAGE 

Subprogram Type : Subroutine 

Calling Sequence : CALL XPAGE 

Purpose : Initializes for printed output a new page with the standard ANOPP header 

information. The five line ANOPP header follows: 

Line 1 - MM/DD/YY ANOPP LEVEL N1/N2/N3 PAGE N 
Line 2 - Title (16A8) 

Line 3 - Subtitle (16A8) 

Line 4 - Label (16A8) 

Line 5 - blanks 

where N1 , N2, N3 are 1 or 2 digit numbers and N is up to a 6 digit integer. 

3.9.2.37 XPK 

Subprogram Type : Subroutine 

Calling Sequence : CALL XPK(IN,NC f IOUT) 

Purpose : Packs NC characters from array IN (Al) into word IOUT. NC is expected to 

be an integer value between zero and the number of characters per word. 

3.9.2.38 XPKM 

Subprogram Type : Subroutine 

Calling Sequence : CALL XPKM(IN ,NC , IOUT ,LI0UT) 

Purpose : Packs NC characters from array IN (Al) into word array IOUT (A8) and blank 

fills unused words in IOUT array. 

3.9.2.39 XPLAB 

Subprogram Type : Subroutine 

Calling Sequence : CALL XPLAB (LABEL) 

Purpose : Initializes the label line of the ANOPP header for subsequent new page with 

ANOPP header requests. LABEL is an array (16A8) containing 128 characters. 
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3.9.2.40 XPLABQ 

Subprogram Type : Subroutine 

Calling Sequence : CALL XPLABQ(L) 

Purpose : Determine current label line of the standard ANOPP header. Output array L 

(16A8) will contain the current 128 character label line. 

3.9.2.41 XPLINE 

Subprogram Type : Subroutine 

Calling Sequence : CALL XPLINE( LINES) 

Purpose : Keeps a running count of lines printed thus far on the current page and 

detrmines if the number of lines remaining on the current page are sufficient for this 
print request. If page is not sufficient, a new page is started. 

3.9.2.42 XPUTP 

Subprogram Type : Subroutine 

Calling Sequence : CALL XPUTP( PNAME , ITYPE, VALUE) 

Purpose : Establishes or changes a User Parameter value in the User Parameter Table 

(UPT) or User String Table (UST). A User Parameter is a numerical, logical, or character 
string value which is maintained in the UPT or UST throughout ANOPP and may be changed or 
retrieved. 

3.9.2.43 XSORTF 

Subprogram Type : Subroutine 

Calling Sequence : CALL XSORTF ( KEY, LR, NR, IB) 

Purpose ; Sorts NR records in a core block IB of records having 
ascending binary sequence. The records are to be sorted in terms of 
record whose index within the record is specified by KEY. 


fixed length LR in 
the word within the 
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3.9.2.44 XSTORE 

Subprogram Type : Subroutine 

Calling Sequence : CALL XSTORE ( NAME , VALUE) 

Purpose : Stores a value into the Executive System Parameter specified by NAME (A8). 

The type of the value is expected to correspond to type defined for the parameter. Valid 
input names and values follow: 

Valid Name Residence Type Range of Values 

NERR /XCVT/ LOGICAL .TRUE, only 


Description: Executive System parameter for error encountered while executing 

a control statement. Functional module sets NERR to .TRUE, to indicate an 
abnormal termination upon return to Executive Manager. 

3.9.2.45 XTBDMP 

Subprogram Type : Subroutine 

Calling Sequence : CALL XTBDMP( ITBL ,ITYP) 

Purpose : XTBDMP dumps the system table in array ITBL having the table type specified 

by ITYP. Valid system table types are 1, 2, or 3. 

3.9.2.46 XTRACE 

Subprogram Type : Subroutine 

Calling Sequence : CALL XTRACE(LIMIT) 

Purpose : XTRACE provides a subroutine traceback capability which prints the names of 

the called and calling subroutines and the lines from which the called routine was called. 
The input variable limit indicates the name (A6) of the subroutine to which to trace or 
the integer number of levels to traceback. If LIMIT is zero or negative, a trace to the 
primary overlay level is done. 
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3.9*2.47 XT1AL 

Subprogram Type : Integer Function 

Calling Sequence : XTIAL(LOC) 

Purpose : Calculates the current allocated length of a system Table Type 1 given LOC , 

the first word of the table preface. 

3.9.2.48 XTirV 

Subprogram Type : Subroutine 

Calling Sequence : CALL XT1FV(ITBL, KEYVAL, KEYLOC, ICONT, IPOS) 

Purpose ; searches a Type 1 System Table or Directory, ITABL, for an entry having the 
specified value, KEYVAL, in a specific position, KEYLOC, within the entry. 

3.9.2.49 XT2AL 

Subprogram Type : Integer Function 

Calling Sequence : XT2AL(L0C) 

Purpose : Calculates the current allocated length of a System Table Type 2 given LOC, 

the first word of the table preface. 

3.9.2.50 XT3FL 

Subprogram Type : Subroutine 

Calling Sequence : CALL XT3FL(IT,IC,IP) 

Purpose : Locates the position, IP, of the last entry in a Type 3 Table given IT, the 

array containing the Type 3 Table, and IC, the position of the character pointer in the 

table preface. 

3.9.2.51 XT3FV 

Subprogram Type : Subroutine 

Calling Sequence : CALL XT3FV(ITBL,ICHAIN, KEYVAL, KEYLOC, ICONT, IPOS) 
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Purpose : Searches a Type 3 Table or Directory for an entry in chain, ICHAIN, having 

the value, KEYVAL, in the specified location, KEYLOC, within the entry. Valid values for 
ICHAIN are NT3USD, used entry chain, and NT30TR, other entry chain. 

3.9.2.52 XT3IF 

Subprogram Type : Subroutine 

Calling Sequence : CALL XT3IF(IT) 

Purpose : Initializes new entries in the free chain of a Type 3 Table given IT, the 

array containing the Table. 

3.9.2.53 XT3LK 

Subprogram Type : Subroutine 

Calling Sequence : CALL XT3LK( IT , IC , IP) 

Purpose : Links an entry into a Type 3 Table Chain. 

3.9.2.54 XUNPK 

Subprogram Type : Subroutine 

Calling Sequence : CALL XUNPK(IN,NC ,I0UT) 

Purpose: Unpacks NC characters from the word IN (A8) into the array I0UT (Al). NC 

must have a value greater than or equal to zero and less than or equal to the number of 
characters per word. 

3.9.2.55 XUNPKM 

Subprogram Type : Subroutine 

Calling Sequence : CALL XUNPKM (IN ,NC ,I0UT) 

Purpose : Unpacks NC characters from the word array IN (A8) into the string array 

I0UT (Al). NC must have a value greater than or equal to zero. 
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3.9.2.56 XUNPKT 

Subprogram Type : Subroutine 

Calling Sequence : CALL XUNPKTC IN ,NC , I0UT ,MAX0UT ,LU0UT ,0VFL) 

Purpose : Unpacks NC characters from the word array IN (A8) into the string array 
I0UT (Al) and truncates an overflow. NC must have a value greater than or equal to zero. 

3.9.2.57 XVNAME 

Subprogram Type : Logical Function 

Calling Sequence : XVNAME(NAME) 

Purpose : Determines if input argument NAME (A8) is a valid name. 

3.9.2.58 XZFILL 

Subprogram Type : Subroutine 

Calling Sequence : CALL XZFILL(NAME) 

Purpose : Removes the trailing blanks in argument NAME and replaces these blanks with 

zeroes. In the event there are blanks preceeding the left most character in the name or 
blanks embedded in the name, these blanks will remain unchanged. 

3.9.3 Auxiliary Modules 

A Utility error processer may be called by any one of the General Utilities if an 
error condition is encountered during its execution. Currently there is only need for a 
fatal error processor. 

3. 9. 3.1 Utility Fatal Error Message Writer (XUFMSG) 

Subroutine XUFMSG (NM,CNAME,VAR1,VAR2) processes the fatal utility errors by printing 
the error message indicated by NUM and aborting through a call to XEXIT. 
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3. 9. 3. 2 System Tables Utility Error Message Writer (XTBERR) 

Subroutine XTBERR (NAME, IERR, IARG, IVAL, ITBL, IPL) processes the error messages 
for some of the utilities which manipulate system tables. NAME is the calling subprogram 
and IERR is the error number. If IERR is negative, the error is fatal and if positive 
non-fatal. IARG and IVAL contain informative values pertinent to the error encountered. 
ITBL and IPL permit the dumping of a table preface where ITBL is an array containing the 
table preface to be dumped and IPL is the preface length. If IPL = 0, no table will be 
dumped. 

3.9.4 Hierarchy Charts 

A hierarchy chart is a graphical representation of the logical relationships between 
modules. Figures 1-12 are the hierarchy charts for the General Utility modules and the 
auxiliary modules. 

All General Utility modules appear at least once as a block entity in the hierarchy 
charts. Detail is to the lowest level module except when the called module is a service 
module (another utility, or a DSM or DBM module), the auxiliary module XUFMSG , or a 
subprogram provided by one of the CDC operating system libraries. However, these modules 
are listed in the hierarchy chart figures. 

Symbols and headings used in the hierarchy charts are given below: 


NAME - module name 
purpose - brief description 


■ i 

j NAME j represents logical module not existing as 

i , entity. It is used for logical groupings. 

1 i 

i i 


NAME 

purpose 


, 


indicates lower level module is called by 
higher level module. 
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implies logical grouping with no direct 
relationship. 


in upper right corner of module block 
indicates module is expanded as a separate 
hierarchy. 


ANOPP MODULE CALLED: 


a list of DBM, DSM , and General Utility, 
modules called by the modules in this figure 


CDC System Library Subprograms Called: 


a list of subprograms called by the modules 
in this figure and which are not part of 
ANOPP system libraries. 
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Figure 1. General Utility Hierarchies 
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Figure 1. General Utility Hierarchies (Continued) 
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Figure 3. XCRD0T Hierarchy Chart 
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Figure 4. XCRDR Hierarchy Chart 
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Figure 5. XCREXP Hierarchy Chart 
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Figure 6. XCRFC Hierarchy Chart 
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Figure 7. XCRILL Hierarchy Chart 







Figure 8. XCRWC Hierarchy Chart 













XEXIT 


GENERAL UTILITIES 



w 

2 

n 

►4 

Ph 

X 


Q) 


id 

o 

CO 

<u 

H 

2 

T5 

O 

2 

Ph 

Ph 

O 

2 

< 


Oh 

X 


X w 
u o 

w P§ 
pH E- 
X X 


*^§ 8 ? 


3.9-29 


Figure 9. XEXIT Hierarchy Chart 
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Figure 10, XTBERR Hierarchy Chart 
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Figure 11. XTRACE Hierarchy Chart 
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4.1 OVERVIEW 

The following subsections describe the procedures for installation and execution 
of ANOPP and of ANOPP Functional Modules. These procedures depend upon the host 
computer operating system, and the loader used to accomplish the loading of multiple 
overlay segments. 

While the examples given in this section have been tested and can be used in 
"cookbook" fashion, many variations of these basic examples are available to anyone 
with a working knowledge of the specific file oriented operating system and loader 
being used. For such knowledge, the reader is referred to the references at the end 
of each subsection. The examples given are specific solution to the general problem 
of getting the right information on the right file, in the right place, at the right 
time . 
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4.2 CDC CYBER NOS WITH THE NASTRAN LINKAGE EDITOR 

Five files are of recurring interest during installation and execution procedures. 
They are a source file, an object file, an executable file, a loader directives file and 
a library file. While these files may be assigned any number of valid names, they have 
been assigned mnemonic names such that their use will be more apparent in the procedures 
described. The names are: 

AN0PL 

AN0PB 

AN0PP 

SUBSYS 

LINKLIB 


ANOPP source file in CDC UPDATE Program Library format. 

object file of relocatable load modules, output from FORTRAN compilation 
and input to Linkage Editor. 

executable load file, output from Linkage Editor. 

Linkage Editor segmentation directives file in CDC UPDATE Program 
Library format . 

load library used by the Linkage Editor to satisfy external references. 
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4.2.1 Installation Procedures 

There are four basic installation procedures. In increasing level of com- 
plexity, they are: 

1. generate an executable file 

2. modify an existing module 

3. install a dummy functional module 

4. install a new functional module 

These procedures involve the five important files, AN0PL, AN0PB, AN0PP, SUBSYS, 
and LINKLIB. At each step the user has the choice of making either temporary or 
permanent changes to these files. These options will be discussed in each procedure 
without giving an example of every possible combination. 

4.2.1. 1 Generate An Executable File 

The executable file, AN0PP, is output in random access mode from Linkage Editor 
processing. The Linkage Editor requires binary load modules, segmentation direc- 
tives, and a LINKLIB. The sample job in Figure 1 illustrates the binary load modules 
coming from AN0PB and the segmentation directives from C0MPILE which was output from 
a CDC UPDATE of SUBSYS. AN0PB is output from compilation of source code that came 
from an UPDATE of AN0PL. In this example, the compilation listing and directive 
listing are printed for future reference, and the binary load modules and executable 
file are permanently saved. 

4. 2. 1.2 Modify An Existing Module 

. If a module in the permanently resident segment, LINKO, is to be modified, then 
a full Linkage Editor run must be made to regenerate every link on the executable 
AN0PP file. Otherwise, it is possible to do a partial Linkage Editor run to 
regenerate only those links containing the modified module or modules. The full case 
uses all of the directives from the SUBSYS file as in generating an executable 
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Figure 1. Generate System From Source Code 
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file. In the partial case a copy of an old executable file is declared as an INFILE 
on the LBIKEDIT directive and only those directives pertaining to the affected links 
are selected from SUBSYS. In either case, the modified source is obtained from an 
UPDATE of the AN0PL file. The modified source is compiled and the corresponding 
modified binary load modules are placed on an LG0 file. The appropriate directives 
are selected from SUBSYS and input to the Linkage Editor along with LG0, AN0PB , 
and LINKLIB. The Linkage Editor will search for load modules on LG0 and AN0PB and 
will give preference to modules named on LG0 if duplicates occur. Figure 2 gives an 
example of a full Linkage Editor run with the executable AN0PP file produced in 
sequential mode. Figure 3 gives an example of a partial Linkage Editor run with the 
executable AN0PP file produced in random access mode. In Figure 2, the direct 
access permanent file, AN0PP, will be written in sequential form by the Linkage 
Editor and must be executed subsequently with an AN0PP. control card. In Figure 3, 
the direct access permanent file, AN0PP, was written in random access format in a 
previous Linkage Editor run and is copied to a local file, MYFILE, that is used as 
both INFILE and 0UTFILE in random access format during this Linkage Editor run. The 
file, MYFILE, is executed subsequently with a MYFILE .ATTACH control card, 

4. 2. 1.3 Temporarily Install A Dummy Functional Module 

The standard executable version of ANOPP has provided for five dummy functional 
modules named FM1 through FM5 to reside in links 5 through 9 respectively. For 
purposes of this discussion it will be assumed that the user has sufficient knowledge 
of the ANOPP executive system and its interfaces to have written the source code for 
a functional module and now wishes to install and execute a test of the module. To 
do this, the user must first understand that the ANOPP control statement EXECUTE FM1 
will really cause the module in LINK5 to be loaded and executed. Likewise for 
FM2/LINK6, FM3/LINK7, etc. Thus, the user must execute FM5 to test a dummy module in 
LINK9 , but the names of the routines in LINK9 need not be FM5. The names of the 
routines in LINK9 are determined by the INCLUDE directives for that link and must 
have been found on LG0 or AN0PB. The following two examples illustrate these 
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Figure 2. Update Source Code and Perform Full Linkage Editor Run 
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concepts. In the first, a dummy module consisting of the single subroutine FM2 has been 
installed in LINK6 , and secondly a dummy module consisting of three subroutines has been 
installed in LINK8. 

In Figure 4, the dummy module source code consisting of the single subroutine FM2 is 
compiled and the relocatable load module FM2 is placed on the file LG0. Then a partial 
Linkage Editor run is performed using the set of directives for LINK 6 called from SUBSYS. 
These directives already have an INCLUDE statement for the dummy routine FM2 . Then the new 
executable version of ANOPP on the local random file MYFILE is executed and the dummy 
functional module is tested via the EXECUTE FM2 control statement. 

In Figure 5, the dummy module source code consisting of the three routines MYM0D, 
MYM0DA, and MYM0DB is compiled and the three relocatable load modules are placed on the 
file LG0. The Linkage Editor directives for LINK8 are supplied from INPUT to reflect the 
overlay structure desired for the three routines of the dummy module to be tested, A 
partial Linkage Editor run is made to construct a new version of the ANOPP executable code 
on a local file, MYFILE. This version contains the new dummy routines in LINK8 . The 
dummy module can be tested by placing an EXECUTE FM4 card in the ANOPP control statement 
set and executing an ANOPP run via the MYFILE . ATTACH control card. 

4. 2.1.4 Permanently Install A New Functional Module 

Permanent installation of a new module requires some minor modif iciations to part of 
the ANOPP executive management system. The primary concern is to match the new module 
name with the new link in which it resides. This is accomplished via matching entries in 
the two arrays FMN and IFMN in the subprogram XRTSEX. The length and contents of these 
arrays are controlled by INTEGER and DATA statements in the same subprogram XRTSEX. The 
number of active entries in each array is controlled by the variable NFM in the common 
block /XCS/ and is set by a DATA statement in the subprogram XCSBD. Array FMN contains 
the names of existing functional modules, and array IFMN contains the corresponding link 
numbers. At present, dummy modules FM1 through FM5 in links 5 through 9 are permanently 
installed. 
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Figure 4, Sample Run To Execute Dummy Functional Module FM2 
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copyei *anopp*myfile 
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Figure 5. Sample Run To Temporarily Install Dummy Functional Module 



MACHINE DEPENDENT INFORMATION 

In Figure 6, an example of adding a new module with the symbolic name NEWM0D is 
given. The module will be placed in LINK10. To begin with, the source code for NEWM0D 
and the required changes to the executive management modules is obtained by an UPDATE of 
the source file AN0PL. In this example, the NFM variable is increased to 6 and the name 
NEWM0D is placed in the array FMN while the link number 10 is added to the array IFMN. 
After compilation, the binary load modules are placed on the file LG0. A full Linkage 
Editor run must be performed since a subprogram in LINKO is being changed. Thus, all of 
the directives from the SUBSYS file plus the new LINK10 directives must be used. The 
new version of ANOPP is executed by an AN0PP. ATTACH card and the new module is tested 
with an EXECUTE NEWM0D control statement. 

In this example, it Is assumed that the new module was previously tested thoroughly 
as a dummy module and that the installation is intended to be permanent. Therefore new 
versions have been created or rewritten for the source file, AN0PL; the binary file, 
AN0PB; the directives file, SUBSYS; and the executable file, AN0PP . 
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Figure 6, Sample Run To Permanently Install A New Functional Module 
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Figure 6. Sample Run To Permanently Install A New Functional Module (continued) 
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4.2.2 Execution Procedure 

Execution procedures involve both the external host computer operating system en- 
vironment and the internal ANOPP executive and data base management system. The external 
system is concerned with initiation of program loading and access to system files. The 
internal system is concerned with interface and access to and between external files and 
internal data base structures. Some operations must occur in pairs or combinations while 
other procedures or control cards act independently. 

4. 2. 2.1 Program Loading 


Loading procedures for the executable program vary depending upon the random or 
sequential mode of the file to be loaded. The executable file is a double file containing 
a bootstrap program and executable program separated by a file mark. The control card 
that loads the executable file actually loads the bootstrap loader program that then 
accomplishes loading of the executable program. The actions taken by this bootstrap 
loader are determined by the form of the control card. If the bootstrap loader program 
and executable program reside on an executable file named AN0PP, then the loading options 
are : 

1. LDSET,LIB=F0RTRAN/SYSI0 . 

AN0PP. ATTACH 

This form is used by the bootstrap loader to execute an executable file that 
exists in random format* A random format is produced by the Linkage Editor as 
an 0UTFILE with R or C status. It can also be produced from a sequential file 
by the bootstrap loader under the CATL0G option (see 2. below). 

2. LDSET ,LIB=FORTRAN/SYSI0. 

AN0PP. CATL0G(XXX) 

LDSET ,LIB=FORTRAN/SYSI0 . 

XXX. ATTACH 

These two control cards must appear in a pair and the name xxx may be any valid 
file name, but must be the same name on both cards. The CATL0G command in- 
structs the bootstrap loader to transform a sequential executable file AN0PP 
into a random executable file xxx. The random file xxx is then executed with 
an ATTACH command similar to 1 above. The file AN0PP must be sequential and 
could only have been produced by the Linkage Editor as an 0UTFILE with S or T 
status . 
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3, LDSET,LIB=FORTRAN/SYSI0 . 

AN0PP. 

This form may be used to execute a sequential executable file output from the 
Linkage Editor. In this case, the bootstrap loader internally generates the 
equivalent of 2 above in the form AN0PP . CATL0G(SYSLM0D) followed by SYSLM0D. 
ATTACH. This form may not be used with random executable files. 

The N0S operating system and FORTRAN extended language together provide the -option of 
changing the names of program files at execution time. This is accomplished via an order 
dependent substitution of file names on the control card that initiates program loading. 
For AN0PP, the two main program files are INPUT and 0UTPUT as declared in the main program 
XM. Alternate file names can be substituted for them by altering the AN0OPP. ATTACH and 
AN0FP. execution sequences above. Substitutions cannot be made with the AN0PP . CATL0G 
card, but may be placed in the xxx. ATTACH command. The substitutions are made by including 
the alternate names, separated by commas, between the final P in AN0PP and the period (.). 
The list is order dependent, but may terminate early. However, leading commas must be 
used to space over leading files for which no substitution is desired. For example: 

AN0PP , ALTIN ,ALT0UT . ATTACH 

AN0PP, ,ALT0UT. 

XXX, ALTIN. ATTACH 

4.2. 2.2 Data Interfaces 

Certain correspondences must be maintained between internal data units and external 
files during an ANOPP execution. Other correspondences can be noted from one execution to 
another. For example, an ATTACH of a data unit and external file must have been preceded 
by a CREATE of the internal data unit and a SAVE of the corresponding external file in 
another run. Most of these restrictions have been mentioned in descriptions of individual 
ANOPP control statements. Two examples of ANOPP executions that illustrate inter and intra 
job dependencies are presented. 

The first job, in Figure 7, begins with attaching a direct access permanent file 
ANjGPP which was previously output as a sequential executable file by the Linkage Editor. A 
sequential external file SEFN is accessed, a direct access permanent file EFN3 is at- 
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ATTACH* ANOPP/NA 
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tached, and another direct access permanent file AN0PX is defined. The ANOPP program is 
loaded and executed via the CATL0G/ ATTACH sequence. The sequential executable file 
AN0PP is transformed by the bootstrap loader into the random executable file AN0PX and 
then loaded and executed via the AN0PX. ATTACH control card. During execution, UNIT1 is 
created with a scratch external file name and UNIT2 is created with an external file name 
EFN2. UNIT3 is created and connected to the externally attached EFN3. Member MEMB1 is 
placed on unit DATA. Member MEMB1 is added from DATA to UNIT1 during the ANOPP UPDATE 
control statement processing. Member TBL1 is placed on UNIT2 during ANOPP TABLE control 
statement processing. UNIT2 is detached from Data Unit Directory but the external file 
name EFN2 remains open in the external system. UNIT3 is ARCHIVED. The remaining non- 
archived data unit in the Data Unit Directory, UNIT1, is unloaded to the sequential 
external file SEFN. The purge of UNIT3 causes the data unit name UNIT3 to be removed 
from the internal unit directory and the external file name EFN3 to be removed from the 
external system file table. Following ANOPP execution, the external file EFN2 is per- 
manently saved as UNIT2 and the sequential file SEFN is replaced. 

The second job, in Figure 8, begins by copying the ANOPP primary control statement 
set from INPUT to an alternate file 0THERIN. Next the sequential external file from job 
1, SEFN, is accessed and the external file equivalent to EFN2 in job 1 is accessed from 
the permanent file UNIT2. Then the previously created random executable file is obtained 
by an ATTACH of AN0PX and loading is initiated via a bootstrap loader ATTACH command with 
the alternate input file 0THERIN substituted for INPUT. During ANOPP execution, the data 
unit UNIT2 is attached into the Data Unit Directory and connected with the existing ex- 
ternal file UNIT2 . UNIT1 is loaded from SEFN after which SEFN is removed from the Library 
File Directory and from the external system file table via the DR0P control statement. 
After all cracking and substituting is accomplished, the CALL control statement eventually 
leads to execution of the AN0PP control statement EXECUTE N0ISE UNIT=UNIT2 ,MEMB=TBL1 $. 
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'MACHINE DEPENDENT INFORMATION 
4.2.3 CPC CYBER NOS DEPENDENCY 

1. Coding Standards Violation; 

2. Direct use of operating system capabilities; and 

3. Interfacing the ANOPP Data Base Manager with the CYBER Record Manager. 

The following paragraphs document what these dependencies are and where they are in 
ANOPP. 


4, 2. 2.1 Standards Violations 


1. Use of the intrinsic functions available /through CDC CYBER FORTRAN EXTENDED. 

2. Use of "no mode" arguments in subroutine and function calls. 

3. Use of named block data subprograms. 


4. 2. 3. 2 Operating System Dependent Subprograms 

a. XBSDFL - This CYBER COMPASS subprogram uses the MEM macro to determine the 

amount of central core memory available for the ANOPP run. 

b. XPURGE - This CYBER COMPASS subprogram uses the UNLOAD macro to dispose of 

unwanted files. 


c. MMCRMX - This FORTRAN subprogram is used by CYBER RECORD MANAGER if an error 

is found in accessing an ANOPP data unit. 

d. XTRACE - This FORTRAN subprogram uses FORTRAN generated trace back struc- 

tures. 

The following subprograms use CDC CYBER Record Manager subprogram calls to perform 
input/output operations: 


1 . 

MMFEFB 

6 . 

MMRMD 

11. 

XLDEND 

16. 

XUN 

2. 

MMGEFB 

7. 

MMRMH 

12. 

XLDFDM 

17. 

XUNBGN 

3. 

MMGET 

8. 

MMUHMD 

13. 

XLDFDU 

18. 

XUNCPY 

4. 

MMMDMH 

9. 

XDR 

14. 

XLDLDM 

19. 

XUNEND 

5. 

MMPUT 

10. 

XLDBGN 

15. 

XLDLDU 

20. 

XUNLUH 


4.2. 3.3 1/0 Interfaces 


On CDC CYBER NOS, the ANOPP Data Base Manager makes use of the CYBER Record Manager 
(CRM) for all input and output. Data Units are written to word addressable files using 
unformatted records. ANOPP Library Files are generated using CRM Internal blocking (I) 


4.2-18 


i 



CDC CYBER NOS WITH THE NASTRAN LINKAGE EDITOR 


and control word (w) record format. On NOS, CRM has FORTRAN callable subprograms which 
are heavily used by ANOPP Member Manager. 
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GLOSSARY 

- The set of names , established on the EXECUTE CS , which corre- 
sponds to a set of reference names. The set of alternate names 
is maintained in the Alternate Names Table and is available for 
retrieval by a functional or an executive system module during 
the execution of that functional module. 

- Functions performed upon completion of functional module to 
insure the integrity of the ANOPP system environment. Includes 
corrective action taken when system conditions are invalid. 

- (CS) One or more card images which define a particular action 
to be performed by the ANOPP EM System. A set of control 
statements defines the execution sequence of an ANOPP run. 

Control Statement Processing Phase - The phase of EM execution in which the control 

statements are processed. 

Control Structure - A table, a directory or any other information block which is 

core resident and not residing on a data unit /member. 

CS - see Control Statement 

DATA - DATA is the data unit created by ANOPP Executive Management 

System. It is used to store data members created as a result 
of the DATA control statement encountered in the Primary Input 
Stream. 

Data Base Management System - (DBM) The subsystem of AN0PP which provides a method of 

storing and retrieving data on auxiliary storage. Used by the 
ANOPP executive system and by functional modules. 

Data Base Structure - A table, a directory, or any other information block which 

resides on a data unit. The general organizational structure 

A-l 


Alternate Names 


Cleanup Procedures 


Control Statement 




GLOSSARY 


of a data unit and a data member are also included as data 
base structures. 

Data Element - One or more words residing on a formatted data record. The num- 

ber of words is determined by the data member format. 

Data Member - (DM) An ordered set of information which resides, in a log- 

ically continguous fashion, on a data unit. The information 
includes user data and Data Member Manager data. 

Data Member Format - Specification which describes the composition of data records 

residing on a data member. The specification for a formatted 
record is a string of element codes. 

Data Record - An ordered set of data elements or words residing on a data 

member. The record may be unformatted or it may be formatted 
as fixed, variable, or card image according to the data member 
format . 

Data Table - A user-created table of data available to the functional module 

for processing. A one-record data member having an internal 
format corresponding to a defined Data Table Type. 

Data Table Type 1 - A tabulated function of n independent variables (present maxi- 

mum = 4) for which acceptable interpolation and extrapolation 
procedures may be defined. 

Data Unit - (DU) A Data Unit is the highest level of the ANOPP Data Base 

Management System data structure that can be referenced directly 

by ANOPP modules. It is physically stored on direct access 
storage devices and is uniquely identified within an ANOPP 
run by a data unit name. A data unit is a set of data members. 

DBM - see Data Base Management System 

DM - see Data Member 
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DSM - see Dynamic Storage Management System 

DU - see data unit 

Dynamic Storage Management System - (DSM) The subsystem of the ANOPP Executive Mana- 
gement System that provides a method of allocating and re- 
leasing blocks of core storage within ANOPP. 

Element code - Descriptor within a data member format used to describe an 

element code for a one word integer element. 

EM - see Executive Management System 

End of Data - (E0D) end of data character ($), recognized by the Executive 

Cracking Module (XCR) and Executive Crack Without Conversion 
Module ( XCRWC ) as the termination of Character string data. 
Utilized primarily as the terminator of control statement 
images . 

E0D - see End of Data 

Error Processing Phase - The phase of EM execution which determines the action to be 

taken when a non-fatal error occurs during the processing of a 
CS. The action depends on the value of system parameter JC0N . 
JC0N = .TRUE, results in the resumption of processing with the 
CS following the CS in error. JC0N = .FALSE, results in the 
resumption of processing with the next PR0CEED CS or ENDCS CS , 
whichever occurs first. 

Error Termination Phase - The phase of EM execution which results in abnormal termina- 
tion of ANOPP with an informative message as to the cause. 

It is entered when an executive module detects an error condition 
which inhibits further meaningful execution. 

Executive Management System - (EM) The subsystem of ANOPP which performs initialization 

and validation of the ANOPP System, directs the sequence of 
processing based on a user-supplied CS set, directs action taken 



GLOSSARY 


after the occurrance of a non -fatal error, and performs a 
normal or abnormal termination. 

F.M. - see Functional Module 

Functional Module - (F.M.) One or more executable modules recognized by the ANOPP 

executive system. A functional module is called into execution 
when the Control Statement Processing Phase encounters an 
EXECUTE CS and transfers control to the Function Module Pro- 
cessing Phase. 

Functional Module Processing Phase - The phase of EM execution which interrupts the CS 

Processing Phase and brings into execution the F.M. specified on 
the EXECUTE CS. Upon completion of the F.M. , the integrity of 
the ANOPP system environment is validated and insured through 
Cleanup Procedures. 

GDS - see Global Dynamic Storage 

General Utilities - a collection of general purpose modules available for usage by 

all executive system routines. Most of the general utility 
modules are also available for use by functional modules. 

Global Dynamic Storage - (GDS) A section of free core storage defined and maintained by 

DSM to provide for inter-module communication and for storage of 
ANOPP directories and tables. GDS resides at the end of a 
user’s field length for the life of an ANOPP run. The length 
is determined by a parameter on the AN0PP CS. 

Hierarchy Chart - A graphical representation of the functional relationship between 

modules . 

IDX - An IDX is an integer variable which contains the location of a 

block of dynamic storage relative to a reference point which, 
for the ANOPP system, is the /XAN0PP/ common block. 
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Index - Location relative to beginning of table or table entry re- 

ferenced with an ordinal of 1 (one). Used primarily in DBM 
module prologues and descriptions. 

Initialization Phase - The phase of EM execution which controlls the initialization of 

the ANOPP system environment, which includes printing of the 
standard ANOPP title page, processing the Primary Input Stream 
through the STARTCS CS and performing initialization func- 
tions for EM, DBM and DSM. 

LDS - see Local Dynamic Storage 

Local Dynamic Storage - (LDS). That part of core storage maintained by the Dynamic 

Storage Management System that begins with the word following 
the longest segment in current execution and ends at the start 
of GDS. 

M001 - The data member name which contains the Primary CS Set on XSUNIT 

data unit. 

Member Manager - ( DMM , MM). That part of the DBM sub-system which provides the 

F.M. writer and the EM subsystem with basic open/close, 
read/write and position functions for creating, accessing, 
and maintaining data members. 

MM - see Member Manager 

Module - A FORTRAN or COMPASS subprogram. 

Mxxx - Name of the data member which contains a Secondary or Primary 

CS Set* 

Mxxx Completed Execution - Completed execution describes the status of an Mxxx member 

when all control statement records on that member have been 
processed. The Mxxx member is not in current execution or in 
suspended execution. 



GLOSSARY 


Mxxx Current Execution - Describes the status of an Mxxx member when that member is 

open and the control statement records on the member are being 
processed. The CS currently in execution is on the Mxxx member. 

Mxxx Suspended Execution - An Mxxx member is put into suspended execution if, during 

processing of the Mxxx member by the CS Processing Phase, a 
CALL CS is encountered. The Mxxx member in current execution 
is closed and processing resumes with the Secondary Input Stream 
specified by the CALL CS. When the Secondary Input Stream is 
completed, the Mxxx member in suspended execution is re- 
opened and processing resumes with the CS following CALL. 

Normal Termination Phase - The phase of ANOPP execution which is entered when CS Pro- 
cessing Phase is complete, and includes printing an informative 
message, closing member M001, and halting execution. 

Parameter Maintenance Functions - A group of general utilities which establish, change, 

or retrieve user parameter values. These include XPUTP, 

XASKP , and XGETP. 

- Word position relative to beginning of table or table entry 
referenced with an ordinal of 0 (zero). Used primarily in 
DBM module prologues and descriptions. 

- . The executable form of the Primary Input Stream constructed 
during the Primary Edit Phase. It resides on the root member, 
M001, on the EM unit XSUNIT. 

- The phase of EM execution during which the M001 root member is 
built from the control statements in the Primary Input Stream. 
This phase follows the completion of the initialization phase. 

Primary Input Stream - The set of card images found in the ANOPP input stream beginning 

with the first image following the STARTCS control statement 
and including all images through the ENDCS control statement. 


Position 


Primary CS Set 


Primary Edit Phase 
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Root Member 
Secondary CS Set 

Secondary Edit Phase 


Secondary Input Stream 
System Parameters 


System Table 

Table Manager 
TM 


- see Primary CS Set and M001. 

- The executable form of the Secondary Input Stream constructed 
during the Secondary Edit Phase and residing on an Mxxx mem- 
ber on XSUNIT . 

- The phase of EM execution during which a CALL control state- 
ment is processed. On the first execution of a CALL CS , the 
Secondary Edit Phase builds an Mxxx type member containing CS 
records that correspond to control statements in the Secondary 
Input Stream. The Secondary Edit Phase provides the environment 
required for the CS Processing Phase to resume execution with the 
first control statement on the new Mxxx member. 

- A set of control statements residing on a data member in card 
image (Cl) format and brought into execution when a CALL CS 

is processed that specifies the member as the DU (DM) parameter 
on the CALL CS. 

- Variables used in determining characteristics of a particular 
ANOPP run. The default values of certain executive system 
parameters may be modified during the Initialization Phase 
via user— supplied values provided on the AN0PP CS. The value 
of user system parameters may be set during CS Processing Phase 
via user-supplied values provided on the SETSYS CS. 

- A data structure used by various executive modules. The table 
structure has two parts, a preface and a body. The preface 
describes the table* s current status and the body contains the 
entries. 

- (TM). That part of the DBM subsystem which provides open/close, 
build, and interpolate functions for data tables. 

- see Table Manager 
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UPDATE Utility 


User Parameter 


Utilities 

Uxxx 


XSUNIT 


- An EM subsystem which provides the AN0PP user with a means of 
building a new data unit using an existing data unit as a basis 
for modification or drawing from data members on several data 
units. It is initiated via the UPDATE CS. 

- A parameter, when once established, remains available to the user 
throughout the ANOPP run. The value of a User Parameter may be 
established or changed during the CS processing phase via the 
PARAM CS. The value of a user parameter may be established, 
changed, and retrieved during the F.M. Processing Phase via the 
Parameter Maintenance Functions. 

- see General Utilities 

- A member, residing on the EM System scratch unit XSUNIT, con- 
taining card image source input data encountered in the Primary 
Input Stream during the Primary Edit Phase. 

- The executive scratch data unit created by the ANOPP Executive 
System modules. It is reserved for ANOPP Executive System usage. 
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B.l EXECUTIVE SYSTEM MODULES 

The ANOPP executive system is comprised of many modules. Each module is part of the 
Data Base Management System, the Dynamic Storage Management System, the Executive Manage- 
ment System, the UPDATE Subsystem, or the General Utilities. In the following section, 
all ANOPP modules are given according to the corresponding executive module in alpha- 
betical order. With the module names are given the Figure number of the hierarchy chart (s) 
which contains the module, and the section number where a description of the module can be 
found (if applicable). 
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Data Base Management System 
B. 1.1.1. Member Manager 

The modules comprising the DBM are listed below. Figure numbers refer to figures in 


Section 3.6,3 
Name 

Figure (s ) 

Section 

MMBAME 

2,13,14,15 


MMBFSI 

3 


MMBFST 

3 


MMBFT1 

3 


MMBFT8 

3 


MMBFT9 

3 


MMBMCI 

4,13,14,15 


MMBMH 

3,14,15 


MMCL0S 

1,4 

3.6. 3.7 

MMCLSE 

4 


MMCRMX 

4,7,11,12,13,16,20,23 


MMD0MC 

4,5,13,23 


MMEDNM 

1,4,8,9,10,12,17,18,19 


MMERR 

6 

3. 6. 3. 8.1 

MMFEFB 

5 


MMGED 

8,17,21 


MMGEFB 

11 


MMGET 

7,8,9,10 


MMGETE 

1,8 

3. 6.3. 5.3 

MMGETR 

1^,9 

3. 6. 3. 5.1 

MMGETW 

1,10 

3. 6. 3. 5. 2 

MMGNEW 

8 


MMGNWE 

8 


MMI0MC 

11,13,14,15,23 


MMMDMH 

4 


MMNWR 

12 


MM0PRD 

1,4,13 

3. 6. 3. 3.1 

MM0PWD 

1,14 

3. 6. 3. 3. 2 

MM0PWS 

1,15 

3. 6. 3. 3. 3 

MMP0SN 

1 

3. 6. 3. 6.1 

MMPUT 

16,17,18,19 


MMPUTE 

1,17 

3. 6. 3. 4. 3. 
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Name 

Figure(s) 

Section 

MMPUTR 

CO 

T" t 
•ET 

3. 6.3. 4.1 

MMPUTW 

1,19 

3. 6. 3.4.2 

MMREW 

1 

3. 6. 3.6.2 

MMRMD 

4,13,20,23 


MMRMH 

13 


MMRRS 

12 


MM S AMD 

2 


MMSFEI 

8,17,21 


MMSKIP 

1 

3.6.3. 6.3 

MMSUD 

22,23 


MMIJHMD 

4 


MKUPMD 

4 


MM VBA 

4,5,7,12,13,16,20,23 


MMVNM 

13,14,15,22 


MMVTD 

13,14,15 


MMVUM 

24 

3. 6. 3.8. 2 


% 
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B.l.1.2 Table Manager 

The modules comprising the TM are listed below. Figure numbers refer to figures in 
Section 3. 6. 4. 7 


Name 

Figure(s ) 

Section 

TMBLD1 

24 

3.6.4. 5.1 

TMCL0S 

24 

3.6.4. 3 

TMEA 

26 


TMEAIN 

26 


TMEARS 

26 


TMEARD 

26 


TMEB 

26 


TMEBIN 

26 


TMEBRS 

26 


TMEBRD 

26 


TMEDI1 

24 


TMEDTB 

27 


TMERR 

25 

3. 6. 4. 6.1 

TMFTE 

24 


TMGEN1 

24 


TMINX 

27 


TMINY2 

27 


TMINEX 

26,27 


TMLIN 

26 


TMLINT 

26 


TMLRS 

26 


TMLRD 

26 


TMM0PN 

24 


TM0PN 

24 

3. 6. 4. 2. 2 

TM0PNA 

24 

3. 6. 4. 2.1 

TMSRCH 

27 


TMSTD 

24,27 


TMTERP 

24,27 

3. 6. 4. 4 

TMTABP 

27 


TMTBL1 

27 


TMTBL2 

27 


TMTBL3 

27 


TMT0PN 

24 


TMVSEQ 

24 
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B.1.2 Dynamic Storage Management System 

The modules comprising the DSM are listed below. Figure numbers refer to figures in 
Section 3.7.5 


Name 

Figure(s) 

Section 

DSMB 

1 

3.7. 3.1 

DSMCAB 

3,9 


DSMC0N 

4,6,7 


DSMDFB 

9 


DSNDLK 

3,4,9 

3. 7. 4.1 

DSMERR 

2 


DSMET 

1,2, 4, 6, 7, 8 


DSMEUX 

2,8,9 


DSKF 

1,3,9 

3. 7. 3. 2 

DSMFLB 

*»,7 


DSMG 

1,4,9 

3. 7.3. 3 

DSMGUB 

4 


DSKI 

1,5 

3. 7. 3. 4 

DSM IDS 

5 


DSML 

1,6 

3. 7. 3. 5 

DSMQ 

1,7 

3.7. 3.6 

DSMR 

1 

3. 7. 3. 7 

DSMRDC 

4 


DSMRLK 

4,9 


DSMRSV 

4 


DSMS 

1,8,9 

3. 7. 3. 8 

DSMU 

1 

3.7. 3.9 

DSMX 

1,9 

3.7.3.10 

DSMXFB 

9 


DSM1ST 

3 
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B.1.3 Executive Management System 

The modules comprising the EM are listed below. 


Section 3.5 

Name 

XAR 

XAT 

XBS 

XBSDBM 

XBSDFL 

XBSDSM 

XBSGCS 

XBSIN 

XBSSP 

XBSTP 

XCA 

XCABST 

XCACL0 

XCAI 

XCAMST 

XCAMXX 

XCANCS 

XCANS 

XCANSP 

XCANWC 

XCATRA 

XCO 

XCSCCS 

XCSCIL 

XCSCRD 


Figure(s ) 
6 

2,6 

3,14 

3 

3 

3 

3 

3 

3 

3 

4,6 

4 
4 
4 
4 
4 
4 
4 
4 
4 
4 
6 

11 

11 

11 


Figure numbers refer to figures in 


Section 


3. 5.4.1 


3. 5.4. 6 
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Name 

F igure(s ) 

XCSCRS 

li 

XCSIL 

4,6 

XCSINT 

16 

XCSL0G 

6 

XCSP 

6,14 

XCSPM 

4,6 

XCSRD 

16 

XCSRS 

16 

XCSSL 

6,11 

XCSST 

11,16 

XCT 

6,7 

XCTBDU 

2,3,7 

XCTBMD 

3,7 

XCTDU 

3,7 

XCTEFN 

2,3,7 

XDR 

6,8 

XDT 

6 

XEN 

6 

XEX 

6,9 

XEXA 

9 

XEXL 

9 

XFM 

1,10 

XFMANT 

10 

XFMDSM 

10 

XFMMM 

10 

XFMTM 

10 

XG0 

6 

XIF 

6,11 

XLD 

6,12 


Section 


3. 5. 4. 3 


3. 5.4.7 


3. 5.4.4 


INDEX OF MODULE NAMES 


Name 

Figure(s) 

XLDALL 

12 

XLDBGN 

12 

XLDCCS 

12 

XLDEND 

12 

XL DERR 

13 

XLDFDM 

12 

XLDFDU 

12 

XLDLDM 

12 

XLDLDU 

12 

XLDVCS 

12 

XLDVUT 

12 

XLINK 

1,10,14 

XM 

1 

XMCSIL 

15 

XMCSPM 

15 

XMERR 

14,15 

XMERRI 

15 

XMRE 

15 

XPA 

6,16 

XPAVTB 

16 

XPR 

6 

XPU 

6 

XRE 

6 

XRT 

14,17 

XRTAMU 

5,18 

XRTBAD 

5,17 

XR7BCS 

5,17 

XRTBLR 

5,17 

XRTCAL 

5,18 


Section 


6, 3*8. 3 


3. 5.4. 5 


3. 5.4.2 
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Name 

Figure(s) 

XRTCSS 

17,18 

XFTDAT 

18 

XRTEND 

10 

XRTI 

17 

XRTLRF 

5,17 

XRTLSA 

4,17 

XRTLSE 

4,5,17 

XRT0DB 

5,17,18,19 

XRTPIN 

18 

XRTRS 

17 

XRTSAR 

19 

XRTSAT 

19 

XRTSCA 

19 

XRTSC0 

19 

XRTSCR 

19 

XRTSDA 

19 

XRTSDR 

19 

XRTSDT 

19 

XRTSEN 

19 

XRTSER 

19 

XRTSEX 

19 

XRTSG0 

19 

XRTSIF 

19 

XRTSLD 

19 

XRTSPA 

19 

XRTSPR 

19 

XRTSPU 

19 

XRT3RE 

19 

XRTSSS 

19 
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Name 

Figure(s) 

Section 

XRTSTA 

19 


XRTSUL 

19 


XRTSUP 

19 


XRTSYN 

5,17,19 


XRTTC 

5,17 


XRTU 

18 


XRTVCS 

5,17 


XSS 

6 


XTB 

6,20 


XTBADV 

20 


XTBAIV 

20 


XTBLD1 

20 


XTBMVA 

20 


XTBPNC 

20 


XTBPVA 

20 


XTBSDV 

20 


XTBSIV 

20 


XTBSNT 

20 


XTBSVA 

20 


XTBVAR 

20 


XUN 

6,21 


XUNALL 

21 


XUNBGN 

21 


XUNCCS 

21 


XUNCPY 

21 


XUNEND 

21 


XLJNERR 

21 

6. 3. 8. 4 

XUNLUH 

21 


XXFMSG 

23 

3. 5.4.8 j 

XXNMSG 

24 

3. 5. 5. 2 
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B.1.4. UPDATE EM Subsystem 

The modules comprising the EM are listed. Figure numbers refer to figures in 


Section 3.8.8 
Name 

Figure (s ) 

XUP 

6,1 

XUPADD 

1 

XUPADS 

5 

XU PALL 

1 

XUPCDT 

2 

XUPCGP 

2 

XUPCHG 

1,2 

XUPCHI 

5 

XUPCHS 

5 

XUPCHX 

5 

XUPCIN 

2 

XUPC0B 

1,2 

XUPC0S 

5 

XUPCPY 

1 

XUPCQD 

5 

XUPCQT 

2 

XUPCS 

1 

XUPDIR 

5 

XUPECE 

5 

XUPECI 

4 

XUPERR 

3 

XUPGPR 

2,6 

XUPINS 

4,5 

XUPLST 

1 

XUPMLV 

4,5 

XUPNEW 

1 
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Name 

Figure( s) 

XUPNMT 

1 , 2,6 

XUP0MS 

5 

XUP0MT 

1 

XUP0ST 

1 

XUPPRE 

1 

XUPRLV 

4 

XUPSRC 

1 

XUPSUM 

1 

XUPSYN 

1,5 

XUPXCR 

1.2 

XUPXFR 

1,6 
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B . 1 « 5 General Utilities 


The modules comprising the General Utilities are listed below. Figure numbers refer 
to figures in Section 3.9.4 

Name Figure(s) Section 


ALPHA 1 

DIGIT 1 

DVALUE 1 

I AND 1 

ICD 1 

ICI 1 

IC0MPL 1 

I DATE 1 

IL0C 1 


ILSHFT 

IMASK 

I0R 

IRSHFT 

ISHIFT 

I TIME 

IVALUE 

IX0R 

MEMNUM 

NUMTYP 

NWDTYP 

RVALUE 

XASKP 

XBSRIN 

XBSRRD 

XBSRRS 


3 . 9 . 2.1 

3. 9. 2. 2 

3. 9. 2. 3 


3. 9. 2. 4 


3.9.2. 5 


3. 9. 2. 6 


3. 9. 2. 7 


3. 9. 2. 8 


3. 9. 2. 9 


3.9.2.10 


3.9.2.11 


3.9.2.12 


3.9.2.13 


3.9.2.14 


3.9.2.15 


3.9.2.16 


3.9.2.17 

3.9.2.18 

3.9.2.19 

3.9.2.20 

3.9.2.21 

3.9.2.22 

3.9.3.23 

3.9.2.24 


3.9.2.25 
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Name 

Figure(s) 

Section 

XCR 

1,2 

3.9.2.26 

XCRADD 

2,8 


XCRCF 

2,8 


XCRCH 

2,8 


XCRCI 

3,6,8 


XCRD0T 

2,3 


XCRDR 

2,3,4 


XCREF 

2, 3, 4, 5, 7 


XCREXP 

3,4,5 


XCRFC 

2,6 


XCRILL 

2,7,8 


XCKPD 

2 


XCRPH 

3,8 


XCRPN 

2 


XCRP0T 

2 


XCRPS 

2, 3, 7, 8 


XCRREN 

2,8 


XCRRND 

6 


XCRSEN 

2,8 


XCRSNM 

3, 4, 5, 8 


XCRSRD 

6 


XCRWC 

1,8 

3.9.2.27 

XCRWCH 

8 


XEXIT 

1,9 

3.9.2.28 

XFAN 

1 

3.9.2.29 

XFETCH 

1 

3.9.2.30 

XFMTQ 

1 

3.9.3.31 

XGETP 

1 

3.9.2.32 
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Name 

Figure(s) 

Section 

XINC 

1 

3.9.2.34 

XM0VE 

1 

3.9.2.34 

XMPRT 

1 

3.9.2.35 

XPAGE 

1 

3.9.2.36 

XPK 

1 

3.9.2.37 

XPKM 

1 

3.9.2.38 

XPLAB 

1 

3.9.2.39 

XPLABQ 

1 

3.9.2.40 

XPLINE 

1 

3.9.2.41 

XPUTP 

1 

3.9.2.42 

XSORTF 

1 

3.9.2.43 

XSTORE 

1 

3.9.2.44 

XTBDMP 

1 

3.9.2.45 

XTBERR 

10 

3.9.3. 2 

XTRACE 

1, U 

3.9.2.46 

XTRL0C 

11 


XT1AL 

1 

3.9.2.47 

XT1FV 

1 

3.9.2.48 

XT2AL 

1 

3.9.2.49 

XT3FL 

1 

3.9.2.50 

XT3FV 

1 

3.9.2.51 

XT3IF 

1 

3.9.2.52 

XT3LK 

1 

3.9.2.53 

XUFMSG 

12 

3.9. 3.1 

XUNPK 

1 

3.9.2.54 

XUNPKM 

1 

3.9.2.55 

XUNPKT 

1 

3.9.2.56 

XVNAME 

1 

3.9.2.57 

XZFILL 

1 

3.9.2.58 
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C.l EXECUTIVE SYSTEM ERRORS 

Following is a list of the error messages and numbers for the Data Base Management 
System, Dynamic Storage Management System, Executive Management System, General Utilities 

and Update. 

The lower case letter n has been used where a FORTRAN name would be printed. The 
lower case letter v has been used where a FORTRAN value would be printed. 

C.i.l Executive Management System (EM) 


C.l. 1.1 Fatal Errors 

Fatal EM errors are processed by XXFMSG. For further description of the XXFMSG 
module, see Section 3. 5. 5.1. Fatal EM errors have been assigned the numbers 1-999. 

All messages are prefixed by: 

*** EXEC ERROR (ERROR NUMBER v) *** (CALLER n) 


The messages and numbers are as follows: 

1 INSUFFICIENT CORE TO EXPAND TABLE. CURRENT LENGTH OF n TABLE IS v. 

2 ERROR IN ANOPP PRIMARY EDIT PHASE. 

3 INSUFFICIENT CORE TO ALLOCATE n TABLES. 

4 MEMCUR, n, IS NOT THE SAME AS THE NAME, n, IN THE MDBT. 

5 INVALID ODB ENTRY. TYPE CODE = v. 

6 INVALID MEMBER TYPE OR MAX NUMBER OF MEMBERS EXCEEDED. TYPE = n. 

7 KRACKED TABLE OVERFLOW. RECOMPILATION NECESSARY TO ALLOW FOR v CARD 
IMAGES PER CONTROL STATEMENT. 

8 MAXIMUM RECORD LENGTH, v, RETURNED FROM ME M^R MANAGER OPEN CALL FOR ^ 
MEMBER n IS NOT THE SAME AS THE MAX CS RECORD LENGTH, v, 

THE LABEL RECORD LENGTH, v, IN THE MDBT. 

9 STATUS, v, RETURNED FROM MEMBER MANAGER POSITION CALL FOR MEMBER n. 
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10 FOR MEMBER n STATUS RETURNED FROM MEMBER MANAGER GET RECORD CALL IS v 
NUMBER OF WORDS EXPECTED v — NUMBER OF WORDS RETURNED v. 

11 REQUESTED LABEL n IS NOT FOUND. 

12 INVALID CONTROL STATEMENT NAME, n, ON CURRENT MEMBER n. 

13 INVALID INPUT n = V. 

14 INVALID INPUT n = n. 

15 UNEXPECTED ERROR RETURNED FROM MEMBER MANAGER CALL. CODE IS v. 

16 INVALID INTEGER, v, USED IN IDENTIFICATION OF EXECUTIVE SYSTEM MODULE 
OR FUNCTIONAL MODULE. 

17 ERROR DETECTED IN ANOPP INITIALIZATION PHASE 

18 UNEXPECTED OUTPUT FROM n. PARAMETER IS n - VALUE IS v. 

19 UNEXPECTED OUTPUT FROM n. PARAMETER IS n - VALUE IS n. 

20 END OF FILE DETECTED IN PRIMARY INPUT STREAM. INSUFFICIENT INPUT FOR 
REQUIRED STARTCS . 

21 THE IRCS BLOCK ALLOCATED IS NOT MAXIMUM REQUIRED FOR XCA PROCESSING. 

22 NONEXPANDABLE TABLE n IS INSUFFICIENT. 

23 SUBSTITUTION TABLE ALLOCATION IS NOT EXACT NUMBER OF WORDS MOVED TO TABLE. 
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C.l.1.2 Non-Fatal Errors 


Non-fatal EM errors are processed by XXNMSG. For further description of the XXNMSG 
module > see Section 3. 5. 5. 2. VAR4 is a ten word array which enables the printing of card 
images and more explanatory error messages. Non-fatal EM errors have been assigned the 
numbers 1001-1999. 

All messages are prefixed by: 

*** EXEC ERROR (ERROR NUMBER v) *** (CALLER n) 


The messages and numbers are as follows: 


1001 

1002 

1003 

1004 

1005 

1006 

1007 

1008 

1009 

1010 
1011 
1012 

1013 

1014 

1015 

1016 
1017 


INVALID LABEL FIELD. 

INVALID OR MISSING CS NAME 

CONTINUATION SEQUENCE EXCEEDS MAXIMUM CARD LIMIT. SEQUENCE IS ARBITRARILY 
TERMINATED. 

REFERENCE MADE TO NON-EXISTENT LABEL = n. 

DUPLICATE n = n. 

GOTO OR IF CS REFERENCES OWN LABEL = n. 

INVALID END* FIELD OR EXTRANEOUS FIELDS DETECTED ON END* CS. 

EXTRANEOUS FIELDS DETECTED ON n CONTROL STATEMENT. 

EOF DETECTED ON INCOMPLETE CS IN INPUT STREAM. IT IS CONSIDERED IN ERROR 
AND IS NOT BEING PROCESSED. 

INVALID CS NAME = n. 

STARTCS CONTROL STATEMENT MISSING. COMPILATION CONTINUING. 

INVALID STARTCS CONTROL STATEMENT. COMPLETE ERROR RECOVERY. 

KEYWORD FIELD IS NOT A NAME OR MISSING = SIGN. PROCESSING CONTINUES WITH 
NEXT ENCOUNTERED VALID FIELD. 

THE INITIALIZATION VALUE FOR n IS INCORRECT. PROCESSING CONTINUES WITH 
NEXT ENCOUNTERED VALID FIELD. 

THE LENGTH OF GLOBAL CORE REQUESTED FOR THIS ANOPP RUN IS v. THE MINIMUM 
LENGTH REQUIRED IS v. 

n IS AN INVALID KEYWORD. PROCESSING CONTINUES WITH NEXT ENCOUNTERED VALID 
FIELD. 

NEXT TO LAST FIELD ON ANOPP CS IS EXTRANEOUS. 
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1018 

1019 

1020 
1021 

1022 

1023 

1024 

1025 

1026 

1027 

1028 

1029 

1030 

1031 

1032 

1033 

1034 

1035 

1036 

1037 

1038 

1039 

1040 


INDEX TO ERROR MESSAGE NUMBERS 
LAST FIELD ON ANOPP CS IS EXTRANEOUS . 

INSUFFICIENT CORE TO EXPAND TABLE. CURRENT LENGTH OF n IS v. 

USER PARAMETER n NOT FOUND IN USER PARAMETER TABLE. 

ATTEMPT TO PERFORM n OPERATION ON TWO FIELDS OF DIFFERENT TYPES. TYPES 
ARE v AND v. 

ILLEGAL FIELD TYPE FOR n OPERATION. TYPE IS v. 

ATTEMPT TO COMPARE TWO n FIELDS WITH INVALID LOGICAL OPERATOR. CODE FOR 

OPERATOR IS v. 

EXECUTIVE ERROR INDICATOR SET TO .TRUE. WHEN PROCESSING n CONTROL STATE- 
MENT. 

MISSING FIELD DETECTED ON n CONTROL STATEMENT. 

INVALID FIELD DETECTED ON n CONTROL STATEMENT. FIELD EXPECTED TO CONTAIN 

n . 

UNRECOGNIZABLE FIELD DETECTED n. 

UNEXPECTED INPUT. PARAMETER IS n - VALUE IS v. 

STARTCS ENCOUNTERED ON ANOPP CONTROL STATEMENT. COMPLETE ERROR RECOVERY. 

DUPLICATE MEMBERS DETECTED ON ABOVE DATA CONTROL STATEMENT. MEMBER NAME 
= n. 

TABLE EXPANSION ON n TABLE UNSUCCESSFUL, n ENTRY NOT ADDED. 

UPDATE OR TABLE (SOURCE = *) CS FORM IS INVALID IN SECONDARY INPUT STREAM. 

SECONDARY INPUT STREAM MEMBER, n, DOES NOT EXIST. 

SECONDARY INPUT STREAM MEMBER, n, IS NOT IN CARD IMAGE (Cl) FORMAT. 

LOCAL DYNAMIC STORAGE INSUFFICIENT TO ALLOCATE ALL BLOCKS NECESSARY FOR 
SECONDARY INPUT STREAM PROCESSING. 

LOCAL DYNAMIC STORAGE HAS BEEN INITIALIZED BUT NOT RELEASED. 

USER LOCK ON n HAS NOT BEEN CLEARED. 

DATA TABLE n ( n ) OPENED BUT NOT CLOSED, TABLE REMOVED FROM CORE. 

DATA MEMBER n ( n ) OPENED BUT NOT CLOSED. LOGICAL CLOSE PERFORMED. 

DATA UNIT n, DATA MEMBER n CANNOT BE OPENED TO READ. 
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C.1.2 Data Base Management System (DBM) 

C. 1.2.1 Member Manager (MM) 

Member Manager module and control statement error messages are processed by MMERR. 
For further description of the MMERR module, see Section 3. 6. 3. 9.1. 

All messages are prefixed by: 

ft** dbm ERROR ) ERROR NUMBER v) *** (CALLER n) 

The messages and numbers are as follows: 

1 BAD INPUT TO SUBROUTINE n. VALUE = v. 

2 DATA UNIT NAME NOT UNIQUE. 

3 EXTERNAL FILE NAME NOT UNIQUE. 

4 DATA UNIT DIRECTORY FULL. 

5 DATA MEMBER DIRECTORY SPACE NOT AVAILABLE. LENGTH OF MEMBER DIRECTORY IS 
n. LENGTH OF DYNAMIC STORAGE BLOCK OBTAINED FOR THE MEMBER DIRECTORY IS v. 

6 BUFFER SPACE NOT AVAILABLE. 

7 BUFFER ALREADY EXISTS. 

8 BUFFER DOES NOT EXIST. 

9 FILE DOES NOT HAVE PROPER HEADER. 

10 DATA UNIT DOES NOT EXIST. 

11 CANNOT GENERATE EXTERNAL FILE NAME. 

12 DATA UNIT DIRECTORY SPACE IS NOT AVAILABLE. 

13 DATA TABLE DIRECTORY SPACE IS NOT AVAILABLE. 

14 ACTIVE MEMBER DIRECTORY SPACE IS NOT AVAILABLE. 

15 MEMBER DIRECTORY SPACE IS NOT AVAILABLE. 

16 XSUNIT NOT CREATED. 

17 DATA NOT CREATED. 

18 OPEN MEMBER COUNT NOT ZERO. 

19 LAST RECORD NOT COMPLETE ON UNIT n MEMBER n. 
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20 LIBRARY FILE DIRECTORY SPACE NOT AVAILABLE. 

21 DATA MEMBER IS ALREADY OPEN ON UNIT n MEMBER n. 

22 DATA UNIT IS NOT IN THE UNIT DIRECTORY. UNIT n MEMBER n. 

23 ACTIVE MEMBER DIRECTORY IS FULL AND CANNOT BE EXPANDED - EXPAND FIELD 
LENGTH AND GLOBAL DYNAMIC STORAGE. 

24 DATA UNIT ALREADY OPEN FOR DIRECT WRITE. UNIT n MEMBER n. 

25 WRITE INHIBITED ON DATA UNIT. UNIT n MEMBER n. 

26 INSUFFICIENT DYNAMIC STORAGE FOR MEMBER MANAGER USE - EXPAND FIELD LENGTH 
AND GLOBAL DYNAMIC STORAGE. UNIT n MEMBER n. 

27 THE DATA MEMBER IS OPEN TO TABLE MANAGER. UNIT n MEMBER n. 

28 DATA MEMBER IS NOT IN MEMBER DIRECTORY. UNIT n MEMBER n. 

29 OPEN MEMBER COUNT IS NEGATIVE. UNIT n. 

30 DATA UNIT OR MEMBER NAME IS MALFORMED. UNIT n. 

31 READ ERROR ON MEMBER DIRECTORY. UNIT n. 

32 READ ERROR ON MEMBER HEADER. UNIT n MEMBER n. 

33 INVALID DIRECTORY OR TABLE ID. 

34 INVALID MODE ARGUMENT INPUT. UNIT n MEMBER n. 

35 INVALID UNIT DIRECTORY ENTRY. UNIT n. 

36 FILE BUFFER ASSIGNMENT FAILED. UNIT n. 

37 INVALID INPUT ARGUMENT. UNIT n MEMBER n. 

38 INVALID MEMBER FORMAT. UNIT n MEMBER n. FORMAT SPECIFICATION IMAGE 
FOLLOWS, n ... n. 

39 MISMATCHED RIGHT AND LEFT PARENTHESES. UNIT n MEMBER n. 

40 UNRECOGNIZABLE FIELD(S) IN FORMAT. UNIT n MEMBER n. 

41 FORMAT FIELD - TYPE = n, VALUE = v. 

42 INVALID VARIABLE FORMAT - VARIABLE REPEAT GROUP MUST BE LAST. UNIT n 
MEMBER n. 

43 INVALID REPEAT GROUP SPECIFICATION - FORMAT IS INVALID. UNIT n MEMBER n. 

44 INVALID ELEMENT SPECIFICATION - FORMAT IS INVALID. UNIT n MEMBER n. 

45 EXTRANEOUS LEFT PARENTHESIS. UNIT n MEMBER n. 

46 UNIDENTIFIABLE SEPARATOR IN FORMAT. UNIT n MEMBER n. 
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47 MORE THAN ONE VARIABLE REPEATING GROUP SPECIFIED. UNIT n MEMBER n. 

48 CYBER RECORD MANAGER ERROR ON PUT. UNIT n MEMBER iv. 

49 PREVIOUS RECORD IS INCOMPLETE. UNIT n MEMBER n. 

50 RECORD LENGTH IS INCOMPATIBLE WITH FORMAT SPECIFICATION. UNIT n MEMBER n. 

51 NUMBER OF RECORDS PUT TO MEMBER EXCEEDS MAXIMUM DEFINED BY THE OPEN REQUEST 

UNIT n MEMBER n. 

52 NUMBER OF WORDS TO BE PUT IS NEGATIVE. UNIT n MEMBER n. 

53 UNUSED. 

54 UNUSED. 

55 LAST I/O OPERATION DID NOT END ON AN ELEMENT BOUNDARY. UNIT n MEMBER n. 

56 THIS CALL MAY NOT BE USED WITH UNFORMATTED RECORDS. UNIT n MEMBER n. 

57 NUMBER OF ELEMENTS TO BE PUT IS NEGATIVE. UNIT n MEMBER n. 

58 TOTAL RECORD LENGTH EXCEEDS FIXED FORMAT SPECIFICATION. UNIT n MEMBER n. 

59 RECORD DIRECTORY IS FULL - INCREASE MAXIMUM NUMBER OF RECORDS IN OPEN 
REQUEST. UNIT n MEMBER n. 

60 NUMBER OF WORDS TO BE READ IS LESS THAN OR EQUAL TO ZERO. UNIT n MEMBER n. 

61 ATTEMPT TO READ BEYOND END OF MEMBER. UNIT n MEMBER n. 

62 CYBER RECORD MANAGER ERROR ON GET. UNIT n MEMBER n. 

63 RECORD ARRAY SIZE IS LESS THAN OR EQUAL TO ZERO. UNIT n MEMBER n. 

64 NUMBER OF ELEMENTS TO BE READ IS LESS THAN OR EQUAL TO ZERO. UNIT n 

MEMBER n. 

65 MEMBER IS UNFORMATTED - IMPROPER USE OF THIS CALL. UNIT n MEMBER n. 

66 NUMBER OF WORDS READ IS INCOMPATIBLE WITH THE FORMAT ELEMENT SPECIFICATIONS 

UNIT n MEMBER n. 

67 NAME( 3) IS NOT A VALID IDX. UNIT n MEMBER n. 

68 INVALID DATA MEMBER NAME OR IDX IN NAME ARGUMENT. UNIT n MEMBER n. 

69 INVALID DATA UNIT NAME OR IDX IN NAME ARGUMENT. UNIT n MEMBER n. 

70 DATA MEMBER IS NOT OPEN FOR THE MODE SPECIFIED FOR THIS CALL. UNIT n 

MEMBER n. 

71 WARNING - OLD MEMBER IS STILL OPEN TO READ FOLLOWING CLOSE OF NEW MEMBER 
OF SAME NAME. UNIT n MEMBER n. 
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72 ATTEMPTED TO CLOSE MEMBER OPEN VIA MMOPWS WHILE ANOTHER MEMBER ON THE SAME 
UNIT WAS STILL OPEN VIA MMOPWD. UNIT n MEMBER n. 

73 INSUFFICIENT GLOBAL DYNAMIC STORAGE FOR MMCLOS SCRATCH COPY. UNIT n 
MEMBER n. 

74 INVALID NAME ARGUMENT INPUT. UNIT n MEMBER n. 

75 INVALID MODE ARGUMENT INPUT. UNIT n MEMBER n. 

The L0AD control statement uses the module XLDERR to process its errors. 

The messages processed by XLDERR are listed below. For further description of 
the XLDERR module, see Section 3. 6. 3. 8. 3 
All messages are prefixed by: 

*** LOAD ERROR (ERROR NUMBER - v) *** (CALLER - n) 

The messages and numbers are as follows : 

1 ERROR v DETECTED BY OPERATING SYSTEM ON FILE n. 

2 INSUFFICIENT LOCAL DYNAMIC CORE IS AVAILABLE. 

3 EXTERNAL FILE NAME n IS ALREADY ASSIGNED TO DATA UNIT n. 

4 THE LIBRARY DIRECTORY RECORD IS INVALID. ID IS n, CNE IS v. 

5 DATA UNIT n IS NOT DEFINED ON SEQUENTIAL LIBRARY n. 

6 DATA UNIT n, DATA MEMBER n IS NOT DEFINED ON SEQUENTIAL LIBRARY n. 

7 NUMBER OF DATA UNITS TO BE LOADED EXCEEDS THE NUMBER OF ENTRIES AVAILABLE 

IN THE DATA UNIT DIRECTORY. 

8 DATA UNIT n ALREADY EXISTS IN THE DATA UNIT DIRECTORY. 

9 FILE NAME /n/ GIVEN FOR DATA UNIT n IS ALREADY IN USE FOR ANOTHER DATA 

UNIT. 

10 FILE NAME /n / GIVEN FOR DATA UNIT n IS IN USE AS A LIBRARY FILE. 

11 LIBRARY FILE ANOMALY, DATA UNIT/MEMBER NAMED IN THE LIBRARY DIRECTORY IS 

NOT ON THE LIBRARY. 

12 LIBRARY UNIT HEADER IS INVALID V. 

The UNL0AD control tatement uses the module XUNERR to process its errors. 

The messages processed by XUNERR are listed below. For further description of 
the XUNERR module, see Section 3.6. 3.8.4 
All messages are prefixed by: 
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*** UNLOAD ERROR (ERROR NUMBER - v) *** (CALLER - n) 

The messages and numbers are as follows: 

1 ERROR v DETECTED BY OPERATING SYSTEM ON FILE n. 

2 INSUFFICIENT LOCAL DYNAMIC CORE IS AVAILABLE. 

3 EXTERNAL FILE NAME n IS ALREADY ASSIGNED TO DATA UNIT n. 

4 SEQUENTIAL LIBRARY FILE n WAS USED IN PREVIOUS LOAD OR UNLOAD. 

5 DATA UNIT n IS NOT DEFINED. 

6 DATA MEMBER n DOES NOT EXIST ON DATA UNIT n. 

The DROP control statement prints its own message for errors encountered. 
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C.l.2.2 Table Manager (TM) 

0 

Table Manager and TABLE control statement error messages are processed by TMERR. For 
further description of the TMERR module, see Section 3. 6. 4. 6.1. 

All messages are prefixed by; a 

*** DTM ERROR (ERROR NUMBER v) *** (CALLER n) 

The messages and numbers are as follows: 

1 ARGUMENT v OUT OF RANGE. ARGUMENT IS n. 

2 INVALID INPUT 

3 DYNAMIC CORE NOT AVAILABLE. 

4 ERROR RETURNED FROM n. ERROR CODE IS v. 

5 INDEPENDENT VARIABLE ARRAY NOT IN MONOTONIC SEQUENCE. ARRAY DUMP FOLLOWS 

v. 

6 INPUT RECORD FROM UNIT n, MEMBER n, NOT IN CARD IMAGE FORMAT. 

7 LOCAL CORE BLOCK FOR CRACK TABLE NOT SUFFICIENT. 

8 VALUE n NEEDED TO BUILD TABLE TYPE n NOT PRESENT. 

9 INVALID VARIABLE NAME n. 

10 INVALID INPUT - CURRENT CARD IMAGE IS NOT CARD EXPECTED. 

11 INVALID INPUT - DUPLICATE VARIABLE NAME n. 

12 ERROR DETECTED ON FOLLOWING CARD IMAGE v, 

13 INVALID INPUT - MISSING FIELDS DETECTED. 

14 INVALID INPUT - FIELD EXPECTED n. 

15 TABLE NOT BUILT. 

16 INVALID VALUE ENTRY, EXPECTED VARIABLE TYPE n - ACTUAL VARIABLE TYPE v. 

17 EXCESSIVE VALUE ENTRIES . 

18 TABLE ON UNIT - n AND MEMBER - n IS NOT OPEN AS EXPECTED. 

19 USER DOESN'T OWN DATA TABLE. 

20 IDX TO THE DATA TABLE DIRECTORY IS INVALID. 

21 NAMED DATA TABLE, n; n, IS ALREADY OPEN TO DATA TABLE MANAGER. 
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22 NAMED DATA TABLE, n, n, IS ALREADY OPEN TO DATA MEMBER MANAGER. 

23 THE DATA TABLE DIRECTORY IS FULL. 

24 THE NAMED DATA TABLE n, n IS NOT DEFINED TO DATA BASE MANAGER. 

25 SUFFICIENT DYNAMIC STORAGE IS NOT AVAILABLE FOR DATA TABLE n, n. 

26 DATA MEMBER n, n, IS NOT A DTM DATA TABLE. 

27 DATA TABLE n, n IS NOT DEFINED TO DATA TABLE MANAGER. 

28 NAME ARGUMENT USED TO CLOSE DATA TABLE n, n MUST BE THE ONE USED IN 
OPENING THE TABLE. 


t 
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C.1.3 Dynamic Storage Management System (DSM) 

I 

DSM error messages are processed by DSMERR. For further description of the DSMERR 
module, see Section 3. 7. 4*1. 

All messages are prefixed by: * 

*** DSM ERROR (ERROR NUMBER v) *** (CALLER n) 

The messages and numbers are as follows: 

1 n IS ALREADY INITIALIZED. 

2 n CORE IS INSUFFICIENT FOR INITIALIZATION. 

3 GDS/LDS OVERLAP. 

4 n IS INVALID DS TYPE. 

5 v IS INVALID DS START ADDRESS. 

6 n IS INVALID DS USER. 

7 MIN IS GREATER THAN MAX. 

8 INVALID IDX FOR n. 

9 n IS ALREADY UNLOCKED. 

10 n HAS ALREADY BEEN OVERLAYED. 

11 n IS NOT INITIALIZED. 

12 MIN OR MAX IS INVALID NEGATIVE LENGTH. 

13 MIN AND MAX ARE ZERO LENGTH. 
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C.1.4 UPDATE 


UPDATE error messages are processed by XUPERR. For further description of the XUPERR 
module, see Section 3. 8. 7.1. 

All messages are prefixed by: 

*** UPDATE ERROR (ERROR NUMBER v) *** (CALLER n) 

The messages and numbers are as follows : 

1 INVALID INPUT = v. 

2 MEMBER MANAGER OPEN TO READ FOR DATA UNIT n, DATA MEMBER n. 

3 INVALID MEMBER LEVEL DIRECTIVE n. 

4 INSUFFICIENT CORE TO ALLOCATE v WORDS. 

5 UNIT = n IS NOT IN UNIT DIRECTORY. 

6 INVALID KEYWORD FIELD. 

7 THE ALL PARAMETER MAY NOT BE SPECIFIED DURING CREATE MODE. 

8 OLDU , NEWU , OR SOURCE UNITS ARE IN CONFLICT. 

9 REQUIRED DATA UNIT IS NOT SPECIFIED. 

10 CURRENT CONTROL STATEMENT NAME IS n. 

11 INVALID KEYWORD = n. 

12 DATA UNIT n IS ARCHIVED. 

13 INVALID LIST OPTION = n. 

14 NUMBER OF RECORDS OR LENGTH OF ARRAY TO HOLD RECORDS IN TRANSIT IS 
INCORRECT. 

15 SOURCE DATA MEMBER CONTAINING THE SET OF UPDATE DIRECTIVES IS NOT IN 
CARD IMAGE FORMAT. 

16 INCORRECT TABLE NAME FOR n TABLE. 

17 DATA UNIT n, DATA MEMBER n IS NOT OPEN TO READ. 

18 DATA UNIT n, DATA MEMBER n IS NOT OPEN TO WRITE. 

19 NUMBER OF RECORDS TO BE COPIED v OR LENGTH OF ARRAY v IS INCORRECT. 

20 DATA MEMBER n ALREADY EXISTS ON THE NEW DATA UNIT n. 
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21 NUMBER OF RECORDS v COPIED TO THE NEW DATA MEMBER IS LESS THAN NUMBER OF 
RECORDS v REQUESTED. 

22 BAD FIELDS RETURNED FROM CALL TO XCR. 

23 INVALID RECORD READ FROM DATA MEMBER UPDATS. 

24 n IS AN INVALID RECORD LEVEL DIRECTIVE. 

25 NUMBER OF CARD IMAGES EXCEEDS MAXIMUM ALLOWED v. 

26 DIRECTIVE INCOMPLETE WHEN END OF SOURCE MEMBER ENCOUNTERED. COMPLETE 

ERROR RECOVERY. 

27 INSUFFICIENT STORAGE FOR CRACKING UPDATE DIRECTIVE. 

28 INSUFFICIENT CORE FOR STORING THE UPDATE DIRECTIVE IMAGE. 

29 DIRECTIVE CONTAINS A FIELD OF IMPROPER TYPE. FIELD SHOULD CONTAIN A NAME. 

30 DATA UNIT n, DATA MEMBER n SPECIFIED TO BE COPIED DOES NOT EXIST ON OLD 
UNIT. 

31 UPDATE DIRECTIVE CONTAINS A FIELD OF IMPROPER TYPE. FIELD SHOULD CONTAIN 
AN INTEGER. 

32 EXTRANEOUS FIELDS ON UPDATE DIRECTIVE. 

33 LAST RECORD TO BE COPIED v IS NOT IN THE RANGE OF RECORDS ON OLDM . 

34 INVALID FORM = KEYWORD FIELD. 

35 RECORD v TO BE INSERTED IS NOT WITHIN THE RANGE OF RECORDS ON OLDM. 

36 INSUFFICIENT CORE TO ALLOCATE OR EXPAND n TABLE. 

37 THE OLDM KEYWORD FIELD IS NOT FOLLOWED BY A DATA UNIT, A DATA MEMBER, OR *. 

38 INVALID NEWM KEYWORD FIELD. NEWM = MUST BE FOLLOWED BY A MEMBER NAME. 

39 INVALID FORMAT FIELD. 

40 INVALID MNR KEYWORD FIELD. MNR = MUST BE FOLLOWED BY AN INTEGER. 

41 REQUIRED KEYWORD OLDM IS NOT PRESENT. 

42 REQUIRED KEYWORD NEWM IS NOT PRESENT. 

43 OLDM = n (IS NOT FOLLOWED BY A DATA MEMBER NAME). 

44 DATA MEMBER NAME n IS NOT FOLLOWED BY CLOSING PARENTHESIS 

45 THE OLDM KEYWORD FIELD IS NOT FOLLOWED BY A DATA UNIT 01 A MEMBER NAME. 

46 THE -DELETE RECORD LEVEL DIRECTIVE DOES NOT INCLUDE RECORD NUMBERS. 

47 LAST RECORD v TO BE DELETED IS NOT GREATER THAN THE FIRST RECORD v. 
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48 RECORD v AFTER WHICH RECORDS ARE TO BE INSERTED, IS LT OLDM REFERENCE 
POINTER v. 

49 INVALID INPUT n = v. 

50 RANGE v = v OF RECORDS TO BE INSERTED NOT WITHIN RANGE OF OLDM. 

51 SOURCE DATA UNIT n, DATA MEMBER n CANNOT BE FOUND. 

52 OLDM DATA UNIT n, DATA MEMBER n CANNOT BE FOUND. 
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C.1.5 General Utilities 


Most General Utility fatal error messages are processed by XUFMSG. However, several 
utility modules which are called mainly by Table Manager in maintaining data tables 
utilize a separate error message module, XTBERR. 

The messages processed by XUFMSG are listed below. For futher description of the 
XUFMSG module, see Section 3.9. 3.1. 

All messages are prefixed by: 

*** UTILITY ERROR (ERROR NUMBER v) *** (CALLER n) 

The messages and numbers are as follows: 

1 ARGUMENT n OUT OF RANGE. ARGUMENT IS v. 

2 ARGUMENT n IS NOT A NUMERIC CHARACTER AS EXPECTED. ARGUMENT IS v. 

3 INVALID INPUT n = v. 

4 ARGUMENT n IS AN INVALID ANOPP TYPE CODE. ARGUMENT IS v. 

5 USER PARAMETER n NOT FOUND IN USER PARAMETER TABLE. 

6 USER PARAMETER TYPE v DOESN'T MATCH TYPE IN UPT v. 

7 REQUEST TO EXPAND n NOT COMPLETE. 

8 INVALID INPUT n = n. 

9 n DYNAMIC CORE NOT AVAILABLE FOR n TABLE ALLOCATION. 

For further description of the XTBERR module, see Section 3.9. 3. 2. 

All messages are prefixed by: 

*** XTB ERROR (ERROR NUMBER v) *** (CALLER n) 

The messages and numbers are as follows : 

1 INVALID CHAIN IDENTIFIER - n = v. 

2 INVALID KEY POSITION - n = v. 

* 

3 INVALID POSITION INDICATOR - n = v. 

4 NO ROOM FOR NEW ENTRIES - n = V. 

5 INVALID SYSTEM TABLE TYPE - n = v. 
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